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The  primary  goal  of  an  Automatic  Programming  system  is  to  generate  programs  from  some 
high-level  description  of  a user’s  problem.  This  task  may  involve  a diversity  of  efforts,  rang.ng  from 
modelling  the  user  to  optimizing  the  final  program  product.  In  particular,  the  choice  of  a suitable 
internal  program  model  will  influence  the  direction  and  capabilities  Of  an  Automatic  Progiamming 
system;  the  form  of  the  language  will  have  an  impact  not  only  on  the  ease  of  the  translation  tusk,  but 
on  the  scope  of  the  program  analysis  for  determining  the  accuracy  of  the  generated  program  as 
well. 


This  research  effort  presents  a system  called  XREP,  which  includes  a formalism  for  w'iting 
programs  that  explicitly  addresses  and  highlights  some  program  construction  and  verification  issues. 
The  formalism,  a production  system,  includes  facilities  for  generating  an  object  and  referencing  i by 
specifying  its  class  type  and  identifying  the  desired  instance  by  providing  some  limiting  predicate, 
the  predominant  method  used  in  human  communication  for  referencing  objects.  XREP’s  language 
interpreter  generates  a graph  that  defines  the  process  under  inspection,  making  explicit  both  whnn 
and  where  variable  bindings  for  generated  objects  take  place.  From  the  standpoint  of  proper  da  a 
structuring  these  extra  dimensions  found  in  the  execution  graph  are  useful  for  analyzing  a program, 
particularly  with  respect  to  ease  of  data  access,  detecting  access  ambiguity,  proper  sequence  cf 
bindings,  and  other  related  issues. 


Another  facet  of  program  writing  includes  the  ability  to  test  thf  final  product  in  order  to 
verify  that  the  program’s  behavior  matches  the  user’s  expectation.  XREP  accepts  an  intention  string 
of  observable  events,  externally  supplied  by  the  user,  for  this  purpose.  Because  the  production 
language  formalism  is  natural  for  a parsing  task,  the  intention  string,  as  a protocol  of  an  instance  of 
the  process  described  by  the  productions,  con  be  parsed  for  acceptability.  The  system  will  thus  be 
able  to  run  iri  two  modes:  generation  (to  produce  a behavior  instance)  or  parse  (determining  whether 
a particular  behavior  instance  could  have  been  generated  from  a given  program). 


In  order  to  show  the  adequacy  of  the  various  representations,  particularly  the  production 
language,  the  execution  graph,  the  form  of  the  data  variables  and  objects,  and  the  intention  string 
mechanism,  specific  automatic  debugging  tecnniques  were  developed  that  apply  to  problems  normally 
found  in  human  communications,  such  as  improperly  stated  loop  control,  ambiguous  references,  and 
data  structuring  faults.  The  nature  of  this  debugging  effort  emphasizes  some  of  the  problems  which 
an  Automatic  Programming  translator  will  face  in  trying  to  convert  human  inputs  into  a computer 
program. 


Though  this  research  investigates  only  one  analytical  phase  of  Automatic  Programming,  *he 
form  of  the  representations  chosen  for  it  has  an  impact  upon  the  entire  effort;  the  capabilities 
displayed  in  this  report  are  meant  as  a showcase  for  those  formalisms.  Thus,  XREP's  variables, 
as  a counterpart  to  natural  language  objects,  are  shown  to  have  an  integrated  place  within  the 
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production  language,  while  their  placement  within  the  execution  graph  promotes  powerful  and 
intuitive  accessing  mechanisms.  The  nature  of  the  production  language  not  only  makes  the  execution 
graph  simple  to  generate,  but  also  associates  them  visually,  making  it  easy  to  relate  analyses  in  the 
graph  to  the  language.  The  intention  string  provides  a reasonable,  if  not  formal,  way  to  specify 
program  expectations,  with  the  production  language  a perfect  vehicle  for  carrying  out  the  associated 
parsing.  And,  finally,  high-level  debugging  techniques  are  shown  to  be  possible  in  a suitably  rich 
environment. 


This  is  part  of  a series  of  reports  describing  ISI  research  directed  toward  reducing  significantly 
the  cost  of  military  software  while  improving  its  application  and  upgrading  the  general  quality  of 
software.  This  report  covers  a significant  portion  of  the  author’s  USC  doctoral  dissertation, 
completed  at  ISI. 


I.  PRO  III. EM  STATEMENT 


l.l  INTRODUCTION 

The  concept  of  a programming  environment  has  added  new  dimensions  to  software  research. 
With  the  advent  of  interactive  use  of  computers  a programmer  can  participate  actively  in  software 
design  and  development.  It  is  no  longer  realistic  to  view  programming  as  a process  of  discrete  steps 
starting  at  composition,  then  alternating  between  submittals  and  debugging  the  results.  Instead  it 
becomes  a dynamic  process  with  unclear  demarcations.  Recent  programming  systems  specificaMy 
designed  to  operate  interactively,  the  best  example  of  which  is  INTERLISP  [TEITELMAN  74],  exemplify 
this  concept  by  also  taking  an  active  role  in  the  programming  process.  INTERLISP  not  only  provides 
tools  to  the  programmer,  but  it  also  “watches"  over  the  process,  giving  aid  when  it  can  by  detecting 
local  errors  and  providing  numerous  "smart"  commands  to  hide  unnecessary  programming  details. 
Only  a limited  attempt  is  made,  however,  to  "understand"  the  program,  a task  which  falls  into  a 
different  area  of  research  called  Automatic  Programming. 


The  final  goal  of  Automatic  Programming  is  to  be  able  to  generate  computer  programs  from 
natural  descriptions  of  the  tasks  to  be  performed.  By  attempting  to  take  over  the  entire  generation 
process,  Automatic  Programming  represents  the  ultimate  extension  of  the  capabilities  of  the 
programming  environment.  Because  of  economics  and  the  state  of  our  knowledge,  any  Automatic 
Programming  system  will  fall  short  of  that  ideal  in  the  foreseeable  future.  But  progress  in  producing 
more  capable  and  active  Automatic  Programming  systems  depends  entirely  on  the  ability  of  the 
researchers  to  understand  and  model  the  programming  process.  A useful  programming  model  must 
cover  a variety  of  tasks:  the  host  of  ways  to  specify  programs,  program  construction  issues, 
verification  and  debugging,  and  so  forth(i).  Yet  this  understanding  is  possible  because  the  domain  is 
limited  to  one  of  processes,  programs,  and  algorithms.  The  diversity  of  this  knowledge  allows 
different  aspects  of  the  total  problem  to  be  researched  separately.  The  investigation  of  these 
independent  areas  contributes  to  the  long-range  project,  while  in  the  short  term  techniques  ure 
discovered  for  extending  existing  software  systems.  Thus  we  can  envision  interactive  Automatic 
Programming  systems  which  work  together  with  a novice  to  produce  a program  from  some  process 
description.  The  efforts  of  this  dissertation  are  directed  toward  this  kind  of  framework,  i.e.,  a user 
using  natural  language  to  interact  with  an  Automatic  Programming  system. 


A system  of  this  kind  must  have  some  basic  knowledge,  including  natural  language 
understanding,  awareness  of  programming  concepts  like  variables,  loops,  scope,  structure,  and 
debugging  capabilities,  all  of  which  must  be  relatable  to  the  human.  The  need  for  a progressive 


<i)  An  overview  o'  Automatic  Programming  can  be  found  in  [BALZER  72]. 
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dialogue  suggests  that  the  form  of  internal  representations  should  be  close  to  the  user’s  original  in 
order  to  promote  a natural  basis  for  communication.  Though  the  present  report  does  not 
directly  deal  with  this  concept,  it  is  the  basis  for  many  implementation  decisions.  The  hypothetical 
nature  of  an  Automatic  Programming  system  forces  any  claims  and  assumptions  to  rely  on  intuition 
rather  than  strict  results.  Still,  as  an  experimental  study  in  representation,  the  results  are 
independent  of  the  Automatic  Programming  framework. 


The  system  to  be  presented,  called  XREP,  consists  of  a language,  an  interpreter,  a monitor,  and 
a debugger.  The  interpreter  and  monitor  execute  the  program  while  building  a representative  graph 
which  is  used  by  the  interpreter  to  carry  out  evaluations  and  by  the  debugger  as  a history  of  the 
process.  The  language,  called  PLX,  is  designed  to  address  three  issues:  (1)  the  program  construction 
task  faced  by  Automatic  Programming,  (2)  the  methods  used  in  natural  language  for  generating  and 
addressing  objects,  and  (3)  the  simplification  of  the  error  detection  and  correction  task  faced  by  a 
debugger. 


Although  not  designed  for  any  particular  Automatic  Programming  system,  XREP  will  be  placed 
within  a hypothetical  framework  in  order  to  better  focus  the  rest  of  the  report.  Figure  1 

displays  this  system  showing  the  transformation  of  the  Original  input  into  a final  program. 


INPUT 


OUTPUT 

PROGRAM 


NATURAL  RELATIONAL  PLX  PLX 

LANGUAGE  FORM  PROGRAM  PROGRAM 


Figure  1.  A hypothetical  Automatic  Programming  system 


The  original  input  is  given  to  a first-pass  natural  language  translator  which  generates  some 
internal  form,  say  a relational  description  of  that  input.  The  next  module  massages  that  description, 
fixing  whatever  it  can  with  its  static  analysis.  Some  of  its  actions  might  include  spelling  correction, 
reordering  procedure  parameters,  altering  colloquialisms,  supplying  obvious  missing  information,  etc. 
The  PLX  program,  the  output  from  that  phase,  is  then  passed  to  XREP  for  an  execution  analysis.  The 
PLX  program  then  enters  a compile  and  optimize  phase  resulting  in  the  final  product.  For  the 
moment  we  will  assume  that  interaction  is  possible  at  any  stage  of  the  processing. 
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Within  this  framework  all  of  the  errors  detected  by  XREP’s  debugger  ©re  English  situations 
which  may  cause  problems  for  an  Automatic  Programming  translator.  Many  of  these  problems  can  be 
better  resolved  at  execution  time,  when  the  dynamic  context  is  available,  than  within  the  static 
environment  of  a translator.  XREP  has  been  designed  on  this  principle. 


The  adequacy  of  all  the  internal  representations,  programming  language  included,  should  be 
measured  by  the  success  cf  the  debugger  ir.  having  compatible  and  understandable  models  of  the 
problem  and  its  solution.  Both  models  are  required  to  understand  a program’s  behavior  and  have 
expectations  of  its  results  from  which  its  correctness  can  be  tested  or  verified.  Understanding 
pnigrams  --  the  prirrwy  Iosjc  of  Automatic  Programming  can  occur  onty  in  such  an  environment. 


Generally  an  experimental  system  produces  some  characteristic  behavior  to  support  its  claims. 
However,  the  proposed  debugging  methods  of  XREP  are  intended  to  augment  the  capabilities  of  an 
Automatic  Programming  system  by  providing  a powerful  enough  framework  in  which  to  address 
program  construction  issues,  as  well  as  do  debugging.  They  must  therefore  be  evaluated  in  this 
larger  context  rather  than  simply  as  debugging  facilities.  Although  we  have  obviously  not  built  a 
complete  Automatic  Programming  system  as  part  of  this  effort,  we  will  attempt  later  to  show 
how  the  features  of  XREP  could  facilitate  such  a system. 


1.2  PROGRAM  HFtllAV IOR  AMD  EXPECTATIONS 


Analyzing  a program’s  behavior  involves  some  expectation  of  its  results,  many  of  which  are 
independent  of  any  particular  task.  Halting,  avoiding  numeric  overflow,  and  addressing  proper  data 
are  expectations  relevant  to  all  programs,  but  specific  expectations  are  obviously  present  as  well. 
When  they  can  be  formally  stated,  the  program  construction  task  can  often  be  automated  and  proved 
correct(ii).  Unfortunately,  few  processes  (especially  long  ones)  can  be  defined  so  functionally.  Yet 
informal  expectations  are  used  by  human  programmers  to  help  check  out  their  product.  XREP’s 
'intention  mechanism,"  which  is  used  to  monitor  a program’s  execution,  is  informal  in  the  same  way. 
The  mechanism’s  function  is  to  help  the  debugger  detect  flaws  (i.e.,  deviations  from  expected 
behavior),  not  prove  correctness.  Still,  the  debugger  car,  extract  much  information  by  noting  what  is 
expected  and  what  is  produced  — information  certain  to  be  useful. 


Given  this  setting  for  a monitor  and  debugger,  the  next  section  will  describe  the.  struciures 
and  formalisms  on  which  they  work. 


(ii)  This  research  will  be  reviewed  in  Section  5.3. 
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1.3  REPRESENTATIONAL  requirements 


The  choice  of  representations  in  XREP  involves  two  design  criteria-  ctr,irt..r«  „ . * 

sSHSe-S-®-- wwmms:  S 


beh^vi^'LdTn^ilL'L^'D^rrT^'irri  ^ *"  pr0C<i“  ^cription,  execution 

emphasize  how  each  influences  the others.  § ' $ ^ S'  DlSCUSSIOn  of  the  'ndiv.dual  issues  will 


Generic  Data 


can  ac^S'XtrrrLr  ,'S  ? "T»  °f  - Automatic  Programming  system 

programmer  needs  to  generate ZocZZ 7.  'Jr"**"  7?  Pr"is£  m°‘tels  °*  " > 

assignment.  Thus,  "X  = 1",  "X  «-  1"  0r  "(SETO  X IT  ^ n * name  a"d  makes  the  Pr0Per 

makes  all  subsequent  references  ,,  !!!„ uty  that  The  preciseness  of  such  an  assignment 
ambiguous  references  i >e,  Humans'  ,h£  °'her  ha<  use  and 

fluency,  they  present  severe  probiems  for  the  understanding  0^.,^^.“  B'Ve  'anEUaee  itS 


a .ranirPneV:d^S:;LC7^VetrCeed  ^ '°  "« 

S3ft 

:?rt^S0nChaP,er  5 Wi"  amPlil^ 


4 


PROBLEM  STATEMENT 


The  Programming  language 


Due  to  the  nature  of  this  project,  a new  production  language,  named  PLX,  was  designed  for 
XREP.  Because  they  did  not  need  to  contend  with  "features"  of  existing  languages,  the  constructs  of 
PLX  could  be  designed  to  focus  directly  on  relevant  issues.  The  justification  for  a production 
language  has  an  even  deeper  basis.  Production  languages  have  a simple  control  structure;  in  fact, 
production  languages  have  too  simple  a control  structure  for  most  programmer’s  use,  which  explains 
not  only  its  absence  in  programming  shops  but  also  its  usefulness  for  analysis.  Understanding  a 
program  s execution  is  simplified  with  a well-behaved  flow  of  control.  However,  the  nondeterministic 
behavior  of  some  production  systems,  including  ours,  can  inhibit  error  detection  by  trying  fruitless 
backup  instead  o*  recognizing  a true  flaw.  To  aid  in  this  case  PLX  has  a "terminal"  operator  which 
the  monitor  uses  in  trying  to  identify  types  of  failures  as  they  arise. 


Another  feature  of  production  systems  is  their  inspectability.  Since  debugging  is  a primary 
concern  of  the  system,  the  programs  on  which  it  operates  must  be  easily  modifiable.  The  production 
rules  maintain  a perspicuity  which  make  them  ideal  for  this  task. 


Finally,  though  not  normally  used  in  thiC  way,  production  systems  can  impose  a top-down 
discipline  on  program  creation.  The  complexity  of  acquiring  a problem  statement  from  a human 
seems  to  dictate  that  an  Automatic  Programming  system  play  an  active  role  in  the  process. 
Top-down  methods  provide  an  excellent  framework  on  which  to  base  such  a dialogue,  with  the 
nonterminals  of  the  language  acting  as  reference  points  for  maintaining  continuity.  Unfortunately, 
traditional  production  systems  tend  to  defeat  the  top-down  benefits  by  having  unnecessary 
nonterminals  solely  in  order  to  produce  the  appropriate  structure.  PLX  solves  this  problem  by 
means  of  a structuring  convention.  The  acquisition  of  a program  is  not  a concern  of  this  dissertation, 
out  ;he  structuring  issue  is. 


Execution  Modelling 


A model  for  understanding  a program’s  execution  must  account  for  many  details  not  found  in 
most  systems.  A Program  Status  Word  or  execution  stack  is  not  adequate  for  analyzing  execution 
behavior.  Besides  presenting  a current  view  of  a process  in  the  form  of  a program  counter  and  a 
data  base,  a model  must  also  address  dynamic  issues  accounting  for  the  history  of  the  entire 
execution  process:  how  control  was  passed  and  gained,  when  and  where  variables  were  bound,  and 
what  data  are  available  to  a particular  event.  At  tne  same  time,  that  model  should  reflect  the 
program  it  represents.  In  other  words,  the  production  language  and  execution  model  should 
accommodate  each  other;  the  language,  by  simplifying  the  model’s  construction,  the  model,  by 
maintaining  the  structure  imposed  by  the  language. 


In  XREP  a threaded  tree  structure,  called  a Process  Elaboration  Graph  (PEG),  and  an  Access 
Graph,  which  is  just  another  view  of  the  PEG,  atisfy  those  requirements.  By  emphasizing  control 
issues  and  maintaining  closeness  to  tne  production  rules,  the  PEG  becomes  the  focus  of  the  program 
modification  algorithms.  The  Access  Graph  emphasizes  a different  picture  of  the  execution  by 
accentuating  access  and  scope  issues.  That  is,  given  an  event  in  the  Access  Graph,  the  data  in  its 
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scope  of  reference  are  immediately  observable.  The  discussion  of  the  generic  data  types  depends 
upon  this  view  of  the  PEG,  since  a graphic  representation  of  all  the  bindings  is  necessary  if 
complicated  references  are  to  be  accurately  resolved.  The  global  nature  of  the  Access  Graoh 
provides  a natural  environment  in  which  to  view  structural  flaws  that  cause  access  errors. 


Program  Intentions 


Without  a formal  expectation  of  a program’s  performance,  any  debugging  or  understanding 
system  will  only  be  able  to  react  to  task-independent  problems.  The  ability  to  match  expected 
behavior  to  actual  behavior  will  give  a goal-oriented  direction  to  debugging  efforts.  XREP  accepts 
an  intention  string  for  exactly  that  reason.  The  string,  a sequence  of  "observable"  program  events, 
is  mirrored  in  PLX  by  a TERMINAL  primitive  which  generates  the  "observable  events."  The  system 
will  try  to  match  this  output  against  the  given  intention.  The  intention  string  is  not  meant  to  provide 

a method  for  proof  procedures;  it  is  merely  a tool  to  help  the  system  produce  more  correct 
programs. 


The  cons'ructs  presented  in  this  section  are  designed  to  focus  on  debugging  and  intentions, 
while  also  raising  several  side  issues  important  to  Automatic  Programming.  As  representations,  their 
adequacy  can  be  judged  only  by  the  methods  which  operate  on  them.  The  next  section  will  describe 
the  interit  and  scope  of  those  methods. 


1.4  DERUGGINC  EXECUTION  FUWS 


The  extensive  preliminary  discussion  was  intended  to  stress  the  environment  concept 
fundamental  to  this  report.  The  discussion  of  debugging  will  unify  all  the  formalisms  of  XREP 
by  providing  a coherent  model  in  which  to  picture  the  execution  process.  Figure  2 depicts  XREP  as 
two  logical  parts:  a program  executor  and  a program  debugger. 


A SYSTEM  MONITOR  is  responsible  for  executing  the  PROGRAM  written  in  the  production 
language.  The  monitor  records  the  PROGRAM  BEHAVIOR  in  the  Process  Elaboration  Graph  while 
checking  that  its  behavior  is  consistent  with  the  EXPECTATION,  existing  in  the  form  of  an  intention 
spring.  If  a difference  is  detected,  the  DEBUGGER  is  called.  The  first  step  is  to  IDENTIFY  the  nature 
of  the  error.  That  involves  both  CLASSIFICATION  of  the  problem,  and  an  EXPLANATION  for  its 
existence.  Then  CORRECTION  can  be  attempted. 


PROBLEM  STATEMENT 


Figure  2.  Model  of  XREP 


nrnh,  ^ rT  °f  6rr0rS  COnsidered  by  the  debugger  will  be  limited  to  reflect  some  of  the 
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is  associated  with  loop  co  *'Ol,  and  the  last  deals  with  pronomial  references.  All  four  exemplify  a 
position  taken  by  this  system  design: 


Many  Automatic  Programming  trai  Jation  problems  can  be  resolved  better  by 
studying  dynamic  behavior  rather  than  a static  description. 


The  basis  for  this  decision  comes  from  the  intuitive  methods  used  to  resolve  the  problems.  All  seem 
to  be  naturally  suited  to  execution  analysis. 


Structural  Dependencies 


Computer  science  has  become  very  conscious  of  structured  programming(iii),  a concept  which 
is  important  mamiy  because  it  forces  a programmer  to  design  a solution  to  his  problem  carefully 
before  coding  it.  The  benefits  of  following  the  disciplines  imposed  by  structured  programming  are 
numerous:  the  programs  are  easier  to  read,  understand,  and  modify.  These  advantages  are  gained 
because  of  the  modularity  resulting  from  delaying  various  design  decisions  until  necessary.  That  is, 
any  "abstract  level"  of  the  program  contributes  only  what  it  must  to  the  overall  design.  English 
descriptions  of  process  are  notorious  for  doing  exactly  the  opposite.  Information  is  presented  with 
no  regard  for  the  programming  concept  of  structure.  Neglecting  elegance  for  the  moment,  Automatic 
rogramming  systems  will  have  a difficult  enough  problem  just  in  determining  dependency  issues,  i.e., 
what  data  is  required  for  a process  to  operate.  A linear  (i.e.,  nonhierarchic)  representation  of  a 
process,  coupled  with  a global  data  base,  loses  all  the  structure  inherent  in  English.  Again,  the 
informality  of  English  is  to  blame.  However,  the  structure  is  there;  otherwise  anaphoric  references, 
ellipsis,  and  ambiguity  could  not  be  viable  communication  tools.  Automatic  Programming  must  find 
that  implicit  structure  to  be  able  to  write  any  program,  structured  or  otherwise.  The  debugging 
effort  for  these  problems  accentuates  the  help  that  execution  analysis  can  provide. 


Consider  an  Automatic  Programming  system,  structuring  a process  stated  in  English,  trying  to 
deal  with  a reference  like  the  next  to  last  person."  If  this  reference  depends  on  the  dynamic 
behavior  of  the  program  (as  do  most  such  references)  the  Automatic  Programming  system  will  have  a 
hard  time  discovering,  statically,  whether  at  least  two  persons  exist  in  the  current  context  for  that 
reference  to  make  sense.  This  problem  is  the  primary  structuring  issue.  Assuming  that  the 
sequencing  of  the  program  is  correct  and  two  players  do  exist,  its  structure  may  present  a context 
in  which  only  one  person  is  accessible  during  the  "next  to  last  person"  request.  In  that  case  XREP 
will  restructure  it  to  make  sense.  The  modification  is  made  possible  by  the  generic  features  of  the 
variables  and  the  history  of  the  process  maintained  by  the  Process  Elaboration  Graph.  The  naming 
conventions  imposed  by  typical  programming  languages  are  too  rigid  to  facilitate  this  kind  of 
analysis.  In  this^example  the  problem  is  too  much  structure.  A related  case  occurs  when  the  "next  to 
the  last  person  request  succeeds,  but  points  to  the  wrong  person;  this  problem  will  be  resolved  by 
a similar  analysis. 


(iii)  See  [DAHL  72]  for  a state-of-the-art  discussion  of  this  topic. 
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Ihe  other  structure  issue  appears  when  a program  is  running  correctly,  but  is  too  linear; 
access  to  unneeded  information  typif  es  that  flaw.  That  is,  an  event  has  more  information  than  it 
needs  to  accomplish  its  task.  The  form  of  the  generic  data  suggests  a method  of  detection  by  having 
the  system  maintain  a count  of  each  generic  type  produced.  If  the  associated  maximum  is  known  and 
exceeded,  a problem  of  this  type  can  be  hypothesized.  The  position  taken  by  the  debugger  is  that 
an  iterative  process  is  a*  fault.  The  debugging  effort  involves  finding  the  iteration  point  and 
modifying  it  so  that  the  overflow  is  correct?  i. 


The  impetus  for  handling  this  problem  corr.es  from  future  execution  considerations.  Later 
accesses  to  this  data  may  be  ambiguous  because  of  the  extraneous  data.  Also,  this  kind  of  program 
structure  is  not  conducive  to  future  modifications.  Since  the  condition  is  detectable,  fixing  it  seems 
appropriate.  Humans  handle  this  situation  by  automatically  maintaining  contexts  containing  only 
necessary  information.  Unfortunately,  this  structure  is  not  transmitted  in  their  description  of 
processes.  Still,  experts  in  venous  fields  have  the  ability  to  effectively  manage  their  information  by 

structuring  it  to  ease  future  access  to  it.  The  debugging  effort  here  attempts  to  do  the  same  in  this 
special  case. 


Loop  Control 


Erroneous  loop  control  is  another  "feature"  of  natural  language.  Examples  will  demonstrate 
how  humans  determine  iteration  points  dynamically  from  imprecise  and  ambiguous  algorithms  This 
problem  will  be  viewed  in  terms  of  why  it  exists  and  how  it  might  be  resolved  given  the  environment 
presented  thus  far.  Only  a partial  solution  will  be  offered,  with  no  implementation,  since  a complete 
analysis  of  this  Kind  of  situation  is  the  focus  of  other  research  projects. 


/I m/iifiuous  Reformers 


Anaphoric  references  present  the  basis  for  the  next  analysis.  Consider  a reference  like  "the 
first  one.  Syntactic  clues  may  not  find  the  referent  if  the  situation  is  ambiguous.  English  abounds 
with  such  constructs,  forcing  language  translation  systems  to  deal  with  them.  The  PLX  generic  data 
forms  provide  a natural  interpretation  for  this  problem  as  an  unknown  type,  while  the  intention 
string  gives  the  capability  to  resolve  it.  The  ease  with  which  this  can  be  done  strengthens  the 
position  to  delay  binding  decisions  as  far  as  possible. 


The  class  of  errors  reviewed  in  this  section  is  not  meant  to  be  complete.  They  cover  a 
variety  of  typical  situations  which  arise  when  dealing  with  natural  language.  The  formalisms  attempt 
to  simplify  the  manifestation  of  those  errors,  thus  enhancing  the  ability  to  correct  them.  If  th-.-se 
problems  can  be  solved,  the  fluency  gained  in  communication  with  humans  will  allow  an  Automatic 
Programming  system  to  consider  the  program  construction  issue  more  directly. 


S 


problem  statement 

L5  PHILOSOPHY  OF  PROGRAM  UNDERSTANDING 


S'nce  prograni  understanding"  encompasses  such  a variety  of  efforts,  a review  of  the  intent 
of  this  dissertation  is  needed.  Rather  than  formalizing  requirements  which  define  understanding  we 
have  presented  an  environment  in  which  understanding  can  be  demonstrated.  This  environment 
includes  several  rew  constructs,  whose  inclusion  is  justified  by  the  resulting  methods.  The 
advantage  of  this  approach  is  also  its  weakness;  the  flexibility  gained  by  having  loosely  connected 
formalisms  prevents  the  consistency  required  for  proof.  Thus  in  most  cases  methods  are  heuristics 
while  constructs  are  justified  in  order  to  promote  a desired  behavior.  Not  enough  is  yet  known 
abou  programming  to  impose  enough  structure  to  formalize  Automatic  Programming.  Yet,  useful 
results  can  be  extracted  if  completeness  criteria  are  not  demanded.  The  environment  concept 
occupies  a middle  position  in  a spectrum  which  has  batch  comDuting  on  one  side  and  total  Automatic 
Programming  on  the  other.  There  is  no  need  to  sit  at  one  end,  waiting  for  enough  progress  to  make 

e complete  jump  to  the  other.  This  philosophy  addresses  the  immediate  applications  made  possible 
by  Automatic  Programming  research.  H 


2.  AN  INTRODUCTORY  EXAMPLE 


2.1  INTENT  OF  THE  EXAMPLE 


The  object  of  th.s  chapter  is  to  introduce  XREP  and  its  formalisms  in  the  context  of  a 
method  r examp  e;  An  faly5ls  of  ,he  -nSllsh  statement  for  that  example  will  disclose  communication 
Txamot  Un,T  ° na  ura  language.  Section  2.3  will  present  a possible  program  for  this 
example,  emphasizing  specific  constructs  of  XREP’s  production  language  suitable  for  these 
communicat'on  methods.  An  execution  of  this  program  is  then  shown  via  the  process  graphs 
followed  by  a general  discussion  of  how  the  intention  string  mechanism  can  be  applied  \o  Ms 

fnr  H6m'  Jhe  8°.a  ,'S,  ° Sh0W  that  ,he  systerY1  «"*tructs  are  both  natural  to  English  and  adequate 
for  describing  and  debugging  processes.  H 


2.2  TIIE  ENGLISH  STATEMENT 


Backgammon,  a two-person  game,  is  the  setting  for  the  example 
of  the  game  are  as  follows: 


The  rules  for  the  Luginning 


Tho  game  start*  by  having  ear h player  roll  a din.  The  player  with  the  largest 
value  makes  the  first  move. 


This  example  has  several  distinctively  English  characteristics  which  are  ignored  by  computer 

hem"  in?'  el\u  6 d,s,cussed  here  in  of  the  English,  while  the  next  section  will  review 

them  in  terms  of  their  impact  on  XREP's  production  language. 


The  beginning  of  the  statement,  "The  gr,me  starts  by  . . . ,"  introduces  an  immediate  problem 
by  implying  that  the  top-level  structure  of  BACKGAMMON  is  the  start  followed  by  the  rest  of  the 
game,  without  clarifying  whether  the  rest  of  the  game  depends  on  the  start.  Humans  do  not  require 
exp  hat  instructions  to  hep  maKe  distinctions  of  this  sort.  However,  if  an  Automatic  Programming 

made  hv^itlT"8  stri;ctur® , thls.  Proce“  and  the  distinction  is  important,  any  tentative  decision 

JJrd*bmy  l ransja  °r  sh°“ld  5e  s,mP|e  t0  ur|bo  if  proven  wrong.  A major  reconstruction  effort  for 
tnij  common  situation  would  be  undesirable. 
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a zrz-Jtr**  tt  v -h  ~*w 

:r,r>a  r°t ai 'sasi 

view  implies  the  existence  if  an  addressable  ° '.^e  mdlvld‘,s' PlaVers  •«!>  rolling  a die.  The  former 
retrieved  only  by  a request e a composition  can  be 

second  line  of  the  pame  said  "Th*  ni  .®  , e mdePendent  actions.  For  example,  if  the 

because  the  player  referent  does  nnt  m,a^es  (he  f'rs*  m0ve»"  an  ambiguous  situation  arises 

Since  no  individual  player  exists  in  toaUontoy?  so*  'th  mult'ple  ccrnP°nents  of  the  die-rolling  unit. 
.0  -be  die-rolling  ul  Is,  £ *>  ^ ^ * — 

anapho^r^ere^ce'm  Wne  two^The pTlyer' wi^lhe' 1^  'T  T'"™'  me,h°dS  exemplified  bY  the 
hy  type  and  referenced  by  th^t  type  wit  Tr  ^i  * -formation  is  created 

some  context,  enough  clues  usually  exisT  to  1'  T T*  Since  the  da,a  is  crea»«d  - 

this  assumption;  the  predicate  format  is  one  way  to  y'  ^naph0nc  reference  is  based  on 

this  reference  is  also  the  one  necessary  to  address  th^  X C arac  ®nstlc  '"formation.  The  form  of 
previous  paragraph.  The  predicate  part  of  the  refe  6 C°mp0nents  of  ,he  uni*  introduced  in  the 
the  unit’s  format,  thus  distinguishing  it  from  a .e„er"^  * 

prOgram^min^anguages^n  vvay6  procedures  a^re^tovoked^P^o1"  be,Ween  EnBlish  a"d 

parameter  passing  mechanism  to  identify  a procedure  and  ts  ""  gram.mmt?  ,anEuages  use  a formal 
it  creates  information  as  necessary  expecting  (he  i„  ■ V'8™?  Engl,sh  d°eS  not‘  lnstead 

context  and  "find"  what  they  need  In  toe  examo e » - t P'°CedureS  *0  search  their  current 
of  the  dice.  The  English  descrtotior'  does  not  to,?’  k pr0cedure  « to  follow  the  rolling 

than  "the  piayer  with  the  largest  value"  precipitates  that  act  fa*  ^ ^ ^ * f°  U$e  °ther 


to  mo/e^the;0::  to5  P6rVerSe  The  desig"  decisior 

a desirable  feature  for  a target  lanpuiV  ??  d a he  presump,l0n  *ha*  "closeness"  to  English  i« 
modelling  English,  the  language  Lso  LdelTnpikhd  fl' P;°gramming  sys*e™-  By  accurately 
the  manifestation  of  an  error  relatable  to  the  original  text  Specify,n8  Programs,  thus  making 
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2.3  /]  PI.X  PROGRAM 

• trrt  . F'8IJre  .(i) * 3u  Sh°WS  3 pr05ran'  written  in  PLX  which  represents  the  BACKGAMMON  segment 
introduced  in  the  previous  section. 


BACKGAMMON  :=  START  , REST-OF-GAME 
START  :=  (GENSEQ  PLAYER  ->  ROLLDtE)  ->  COMPARE 
ROLLDIE  :=  (GENMEM  OIEVAL) 

COMPARE  (INSERT  PLAYER.( INDEX  MAX  DIEVAL))  ->  FIRST-MOVE 
FIRST-MOVE  (TERMINAL  PLAYER.-l  ’MOVES’) 

REST-OF-GAME  :-  . . . 


Figure  3.  Rules  for  beginning  of  Backgammon 


In  order  to  ease  the  discussion,  the  production  rules  are  simplified  and  use  in  place  of 
program  segments  , .relevant  to  the  discussion(i).  After  the  first  rule  is  initially  viewed  abstractly  to 
explam  the  basic  operations  of  production  systems,  all  the  rules  will  be  inspected  from  two 
standpoints:  their  role  in  the  program  and  their  derivation  from  the  English. 


A rule  has  three  parts:  a left-hand  side,  a rule  separator,  and  a right-hand  side.  For  the  first 
production  they  are  BACKGAMMON,  and  "START , REST-OF-GAME”  respectively.  The  left-hand 
sides,  also  called  nonterminals,  represent  the  names  of  processes  whose  definitions  are  given  by  the 

RKT^gamE1,18  hMd  Sid6S‘  ThU?  BACKGAMM0N  is  3 process  made  of  »wo  P^ts,  START  and 


To  start  operation,  the  production  system  finds  a definition  for  its  distinguished  beginninp 

B A C KP ammoi ru*  rhl!  CTAD TBACKGAMMOr'J-  0nce  a definition  is  found,  it  is  executed.  So,  to  piay 
BACKGAMMON,  first  START  is  executed,  then  REST-OF-GAME  takes  control.  Notice  that  since  START 

is  also  a nonterminal,  the  same  process  that  was  applied  to  BACKGAMMON  is  applied  to  START.  This 
recursive  expansion  of  nonterminals  stops  when  terminals  are  encountered(ii). 


The  symbols  between  the  events  of  the  right-hand  sides  (",’’  and  "->")  have  no  bearing  on  the 
r er  of  execution;  control  in  XREP’s  production  language  is  the  same  as  that  in  standard  production 
sys  ems.  Their  role  will  be  explained  shortly,  during  the  discussion  of  the  individual  rules. 


The  first  production 


BACKGAMMON  :•  START  , REST-OF-GAME 


(i)  A complete  definition  of  the  language  is  given  in  Chapter  3. 

(“I  bee  [G^SBURG  6fi]  f°r  a formal  view  of  production  systems  (or  rewrite  systems  as  they  are 

OtTPn  ra  pH  ) * 
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is  a simple  rule  composed  of  two  nonterminals,  START  and  REST-OF-GAMF  While  the 


event  is  not"  Co'nsidt  T 7^'°:  ^ ^ $C°Pe  °f  '"fo-a"°"  *0r  e^h 

would  be  on  a separate  branch  from  START  because  both  are  in  tteTame^^^ 

the  information  generated  by  START  available  to  RFRT-OF-rAU P . ° e‘  To  make 

information  can  be  made  global  or  some  descendant  of  START  can  gene^airRErT-OF-OrME^t  the 

benefitT^lhjded  to' ^arl i^r 6 ' ^ns tea'd'  XR^P’s^anguap^6  ^ TT  ^ ,h“  f°P -d0Wn 

,1  event  , ,0  have  acc^Xs'ZE^  ZZt 

s-riris  srrr1  d~ ■« — 


indt  endlnt  f'.JSt  Pr°ductl0r;  rUe-  lS  hypothesized,  meaning  that  START  and  REST-OF-GAME  are 
pendent.  If  that  assumption  is  wrong,  just  replacing  by  corrects  it  The  simdicitv  of  thie 
change  is  meant  to  model  the  apparent  absence  of  th.s  problem  in  E Nsh  w ere  tract 

SiS=S-“-»A^TJS 


The  second  production 


START  :=  (GENSEQ  PLAYER  ->  ROLLDIE)  ->  COMPARE 

rr- "Each  piayer  roiis  * *■ 

(1yh,rh  £ * rL«itK  > KULLUlfc.)  is  the  first  example  of  a compound  event  i e nno 

of  independent  7cLT"?he' ^•-t-'befween  * *‘r«ture  consisting  oi  a s'eries 

xx.  w tirj^r"  r ,his  vrs  lish 

Lmh.rl  ti,  t'  A.  , “E  SE0  iBenerate  sequence)  would  be  replaced  by  GENMEM  (generate  a 
member).  Thus,  both  forms  "each  X do  V"  and  "an  X does  V have  an  interpretation  in  the  language 

COMPARE  exists  as  a convenience  to  distinguish  the  action  of  rolline  the  dice  from  th« 
GENSeEQ°a"nS  i „ de^ndanff ' SePara'6S  " ',0r"  GENSE  C0UPARE  d°e!  h-e  •»  both 


The  third  rule 


ROLLDIE  (GENMEM  DIEVAL) 

has  an  example  ot  a simplified  use  of  the  GENMEM  primitive.  Notice  that  the  English  did  not  describe 
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how  to  roll  a die,"  so  inclusion  of  this  rule  reflects  its  need  because  of  the  action  of  the  next 

droduct'on.  In  any  case,  this  production  defines  the  ROLLDIE  process  as  the  generation  of  a member 
of  the  set  DIEVAL. 


The  fourth  rule 


COMPARE  (INSERT  PLAYER.ONDEX  MAX  DIEVAL))  ->  FIRST-MOVE 

represents  the  statement  "The  player  with  the  largest  value  moves  first."  The  rule  contains  the  first 
example  of  a reference  to  a generic  data  type.  PLAYER.ONDEX  MAX  DIEVAL)  follows  the  general  form 
n,y where  'exP"  ls  some  selector  function  pointing  to  a specific  instance  of  "type"  Here 
PLAYER  is  the  type  and  (INDEX  MAX  DIEVAL)  is  the  identifying  expression. 


INDEX  is  a Unction  which  searches  the  appropriate  GENSEQ  structure  in  order  to  find  the 
required  item  — in  this  case,  the  largest  DIEVAL.  Since  each  player  is  associated  with  a DIEVAL 
pointing  to  a particular  one  identifies  the  PLAYER  who  rolled  it.  The  affect  is  like  saying  JOHN’S  5 if 
5 is  the  largest  die  value.  ' 


Once  the  appropriate  player  is  found,  INSERT  sets  him  up  as  the  generator  of  the  FIRST-MOVE 
event.  In  this  sense  it  has  the  same  effect  as  the  compound  event 

(GENMEM  PLAYER  ->  FIRST-MOVE) 

The  difference  is  that  no  new  instance  of  PLAYER  is  created,  an  existing  one  is  merely  repositioned, 
anticipating  future  reference.  So,  if  a descendant  says  "He  moves  ..."  or  "The  last  player 
mentioned,'  the  identification  of  the  referent  will  have  a firm  basis.  This  method  of  having 

fm^  the'r  argUments  is  part  of  a heterarchical  system  design  espoused  at  MIT 
[MINSKY  72]  and  examined  further  by  [WINSTON  72].  It  proposes  that  "smart"  systems  should  know 
ow  o ind  relevant  information  themselves.  The  strict  hierarchy  imposed  by  formal  parameter 
passing  methods  is  not  natural  to  English. 


The  next  rule 


FIRST-MOVE  :=  (TERMINAL  PLAYER.- 1 ’MOVES’) 

results  in  a terminal  output  event.  That  is,  FIRST-MOVE  produces  a string  like  (JOHN  MOVES), 
representing  the  end  result  of  a process.  Another  example  of  a generic  variable,  PLAYER.- 1,  occurs 

Wlthl"  avcJERMINAL  eVent'  Th'S  time  the  predicate  refers  directly  to  a position  — in  this  case,  the 
'a,^r„l:AYER  mentl0ned.  The  ease  of  this  access  comes  from  the  work  of  the  INSERT  primitive,  i.e , 
INSERT  reinstantiates  a type’s  value,  while  type.-l  retrieves  it 


The  intention  string,  described  later  in  Section  2.5,  is  meant  to  match  the  composition  and 
sequence  of  these  TERMINAL  events.  By  placing  the  TERMINALS  judiciously,  various  levels  of  program 
detail  can  be  revealed  for  testing  or  monitoring  purposes.  For  now,  the  TERMINAL  represents  an 
explicit  statement  of  the  computation's  status. 
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This  section  has  viewed  the  production  language  in  terms  of  the  computing  capabilities 
necessary  to  write  programs.  The  next  section,  in  presenting  the  process  graphs,  depicts  the 
production  language  as  a vehicle  for  their  construction. 


2.4  THE  PROCESS  GRAPHS 


l he  structure  which  maintains  a record  of  a program’s  execution  is  called  the  Process 
Elaboration  Graph  (PEG),  The  information  it  contains  and  the  form  it  takes  were  influenced  by  a 
variety  of  design  decisions  dealing  with  the  production  language,  the  generic  data  forms,  and  the 
debugging  capabilities.  Though  reflecting  all  those  issues  internally,  the  PEG  requires  another 
conceptual  view,  called  the  Access  Graph,  to  help  depict  the  spectrum  of  claims  made  for  it.  By 
presenting  a view  in  which  the  production  rules  maintain  their  original  form,  the  PEG  relates  a 
program  and  its  flow  of  control,  thus  becoming  the  focus  of  the  debugging  algorithms.  The  Access 
Graph,  on  the  other  hand,  emphasizes  data  and  scope  issues  by  making  access  paths  visually  explicit, 
a feature  not  present  in  the  PEG.  Through  the  PEG  is  the  only  structure  maintained  by  the  system, 
the  Access  Graph  exists  to  offer  a more  natural  structure  to  view  when  access  is  discussed. 


Assuming  the  players  are  named  Joe  and  John,  Figures  4 and  5 picture  the  Access  Graph  and 
the  PEG  for  the  current  example.  The  difference  between  them  has  an  intuitive  basis  which  will  be 
reconciled  later  in  this  section.  First,  the  construction  of  these  graphs  will  be  compared  to  the  tree 
produced  by  standard  rewrite  systems  in  order  to  emphasize  the  role  of  the  event  separators  and 
the  form  of  the  production  rules. 
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Figure  5.  A Process  Elaboration  Graph  (PEG) 


XRKP  and  Standard  Production  Systems 


The  functionei  events,  like  GENSEQ,  and  the  event  separators  make  XREP’s  production  system 
different  from  others,  yet  by  treating  the  functional  events  as  nonterminals  (while  ignoring  their 
semantics)  and  by  applying  one  transformation  based  on  the  event  separators,  the  rules  can  be  made 
to  look  like  those  of  other  production  systems.  The  transformation  is  as  follows: 


1.  Whenever  "A  B ->  C . . appears  in  a rule,  change  it  to  "A  :=  R”’ 

and  "B’  :*  C " 
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m 


2.  Whenever  "A  . . . B , C . . . " appears,  replace  it  by  "A  :«  . . . B C M 


Applying  these  transformations  to  the  BACKGAMMON  game,  the  rules  become 


BACKGAMMON 

START 

GENSEQ’ 

COMPARE 

INSERT’ 

FIRST-MOVE 

REST-OF-GAME 


START  REST-OF-GAME 
GENSEQ’ 

COMPARE 

INSERT’ 

FIRST-MOVE 


A "standar  d*'  execution  of  this  program  produces  the  tree  structure  shown  in  Figure  6. 


BACKGAMMON 


START 


I 


GENSEQ’ 


I 


COMPARE 


INSERT' 


REST-OF-GAME 


MOVE 

I 

I 


Figure  6.  A standard  tree  structure 


This  traditional  structure  pictures  an  event’s  access  path,  the  path  from  an  event  to  the  root. 
By  containing  all  its  direct  ancestors,  the  access  path  becomes  the  environment  in  which  each  event 
carries  out  its  task;  in  this  sense  it  is  like  the  control  stack  of  traditional  programming  systems. 
Other  than  the  expansion  of  the  GENSEQ  and  INSERT,  the  tree  in  Figure  6 has  the  same  structure  as 
the  Access  Graph  of  Figure  A.  vet  although  Figure  6 depicts  the  context  concept,  the  form  of  the 
transformed  rules  loses  all  the  structural  perspicuity  inherent  in  those  of  Figure  3.  The  event 
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separators  act  as  more  than  syntactic  devices;  they  provide  the  interface  which  gives  the  production 
rules  the  structure  necessary  to  model  a process  naturally. 


Though  the  Access  Graph’s  construction  follows  easily  once  the  convention  of  the  event 
separators  is  known,  by  highlighting  the  access  issues  it  distorts  the  relation  between  the  form  of 
the  production  rules  and  the  sequence  of  their  execution.  The  PEG  maintains  that  relationship,  though 
at  the  expense  of  the  access  issues.  Consider  Figure  5,  the  PEG  corresponding  to  the  Access  Graph 
of  Figure  4.  Its  main  feature  is  its  closeness  to  the  production  rules.  In  fact,  if  the  event  separators, 
encoded  in  the  shape  of  the  events,  were  ignored,  the  PEG  would  represent  an  implementation  of  an 
n-ary  tree  generated  from  a standard  production  system.  For  example,  Figure  7 shows  some  simple 
rules  from  a standard  rewrite  system  and  its  associated  tree,  both  in  a standard  and  implemented 
form.  In  the  standard  form  each  father  points  to  all  his  sons  directly;  in  the  implementation  of  this 
kind  of  tree  (since  that  is  not  a convenient  form)  each  father  points  only  to  his  first  son,  who  in  turn 
points  to  his  right  brother,  with  the  rightmost  brother  pointing  back  to  his  father. 


A A 


A :=  B C D 
B :=  X Y 
X :-W 


Figure  7.  Rules  and  trees  from  a standard  rewrite  system 


The  difference  between  the  implemented  n-ary  tree  conceptualization  and  that  of  the  PEG  it; 
m the  access  path.  In  the  former  case  the  path  is  constructed  by  visiting  all  the  father  nodes,  i.e.,  go 
right  until  an  "up  link"  to  the  father  is  found.  However,  that  method  does  not  work  for  the  PEG 
because  of  the  interpretation  the  event  separators  impose  on  the  rules.  Instead  every  left  brother 
is  visited  (hence  the  two-way  links)  and  inspected  to  see  if  it  is  in  the  access  path.  An  event’s 
inclusion  depends  on  its  shape,  rectangular  if  a follows  it,  or  oval  otherwise.  Basically,  a 
rectangular  event  means  it  is  protected,  an  oval  event  means  it  is  viewable.  Thus,  the  method  to 
determine  the  access  path  in  an  PEG,  trivial  to  define  in  an  Access  graph,  is  to  (1)  visit  the  left 
brother,  (2)  if  it  is  oval  (i.e.,  viewable),  it  and  all  its  descendants  are  included;  if  it  is  square,  the 
event  is  protected  and  not  part  of  the  access  path,  (3)  if  a leftmost  node  is  encountered,  move  up  to 
the  father  and  continue  from  step  1.  This  algorithm  produces  th'  same  access  path  that  can  be  read 
directly  from  the  Access  Graph,  with  the  join  in  the  Access  Graph  corresponding  to  the  viewability 
of  the  GENSEQ  node  by  COMPARE  in  the  PEG. 


20 


AN  INTRODUCTORY  EXAMPLE 


PFr  The  o r aTSn  pa  hS  15  crucial  t0  understandi"S  the  duality  of  the  Access  Graph  and  the 

mann,  Toh  n eC  '°n  ° ? aCCeSS  patl’5  defines  a unique  tree'  The  PEG>  “»der  this  access  path 
mapping,  thus  represents  one  and  only  one  Access  Graph,  i.e.,  the  Access  Graph  is  just  a 

report'^ Fo1-0  now  ^his^t  r°th  ^ °n  different  aspec,s  of  execution  emphasized  by  this 
topic  further  ^ mtuitive  concept  of  access  paths  will  suffice;  Chapter  4 will  detail  this 


I.aitffunffo  Impact  on  the  Proems  Graphs 


prjnhtS  r'  anSua8e  c a,ms  tnacJe  in  the  previous  section  have  a visual  effect  on  the  process 
graphs.  Consider  the  GENSEQ  structure  as  an  addressable  unit  with  independent  branches  The 
P00655  Patl'  °f  contains  GENSCQ  and  all  its  branches  because  of  the  viewability  of  the 

in  COMPAReVV  » (0r/h' v SpmP'e  0b-ervat,0n  that  the  Access  Graph  has  the  GENSEQ  structure 

COMPARES  direct  ancestry).  But  an  event  within  a particular  GENSEQ  branch  (ROLLDIE  for 

whTeP  hi  PFr  ePe."d T'  °V?er  b/rd'es-  Tte  A“e“  ^ ■"•r.ly  ma  J each  brarlcT 'separate, 
the  loin  in  ti  pro‘ects  each  branch  from  the  others  by  making  the  bindings  rectangular.  Notice  that 

h th  • ^i^00^5  GraPh  3fter  the  D1EVAL'S  Set  bounct)  is  conceptual  in  the  PEG,  reflected  only 

by  the  viewability  of  the  GENSEQ  node.  y 


, rh  T.bmdl"5£’  whlCh  result  from  Beating  objects,  also  contribute  to  the  visual  impact  of  the 
ftreccinoM6  T"3  m*char,lsms  force  the  spatial  positioning  of  the  data  within  the  graph, 

where  ^ooteVmPOr  anc?  °‘  kn°Wms  not  0nlY  what  value  an  object  has,  but  knowing  when  and 
the  1!  , f 'ts  va.ue.  Stack  models  also  have  this  information  (though  only  for  a current  branch  of 
the  execution),  but  generally  make  it  directly  available  only  as  a debugging  tool. 


"PI  AVr»?i  'he  'a:18Ui3e  '",lue"ce  is  i"  th.  reintroduction  of  the  binding 

ER.l  -JOE  underneath  the  COMPARE  event.  By  anticipating  PLAYER.- 1 reque5ts,  the  graph! 

P‘;h'  , <°r  even,s  so  that  this  specific  information  is  eitter,  they 

expect  it.  This  implementation  supports  the  English  which  is  likely  to  follow  in  the  example: 


. . . The  player  with  the  largest  value  makes  the  first  move.  He  . . . ." 

G.ven  no  other  information.  PLAYER.- 1 is  a likely  translation  (or  "He."  The  graph  is  ready  for  that 
assumption  by  supporting  the  kinds  of  relative  addresses  used  by  English. 


Review  of  the  Process  Graphs  Features 


h ln,0  mal  discussion  0,  the  process  graphs  was  intended  to  give  some  overall  feeling  for 

y they  exist  and  what  information  each  purports  to  carry.  The  following  features,  used  to 
a uate  a p.ocess  representation,  act  as  a summary  for  this  section  by  reiterating  the  main  issues. 


The  representation  presents  a dynamic  view  of  a process. 
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whVdwLTsUtes  rAhretentS  ;t:uhe  dynamiC  View  COncei'ns  how 

only  the  contextual  information  which  is  necessarv  ^ ^ e*ecutio"  is  required,  to  give  not 
information  to  he,p  debugging  in  case  o,  faiiures.  Th^ 


A spatial  view  of  bindings  is  emphasized. 

The  flexibility  of  the  "tvneovr,"  w,t  t 

process  representation. " To  separate  he"  dT!™"Tb  T “"p  ^ w"hi"  ,h* 

information  loss  and  an  unnatural  (from  the  standool  of  En.T'hT  P°'nt  °nly  lead  *°  ™ 
process.  Both  the  Access  Graph  and  the  PEG  main, a!T  1 spans  ' .l"6"""6"'3'10"  ° ' "* 


• i ic  jjr  uuei 


• cocmjiion  snouia 


wuo 


• / • < 'VOI  I | C 


both  cases“the  proce^rep^res”  n^hon'Thould  5™““'  sdme,imes  drastically,  sometimes  trivially.  In 
to  the  next  one:  flotation  ^ould  be  amenable  to  such  changes.  This  concern  ,s  linked 


• The  process  representation  should  mmror  the  corresponding  program. 

This  condition  is  the  main  claim  made  for  the  PEG  anH  m a 

process  the  manifestation  of  an  error  is  often  ! tr,  i f Pkr0duct,0n  language.  In  executing  a 

error  can  be  difficult.  An  analysis  of  the  PEG  durine  h ? ’ b aSS'Sn,ne  responsibility  for  that 

Common  ancestors  can  easily  be  found  often  n,  r ?ebU^'nS  Can  of,en  ,nvolve  disjoint  branches, 
thus  trie  production  rule  involved  The c!^e  co 1 " J "*  ST'  reSp0nsible  for  the  error,  and 
PEG  makes  this  information  both  findable  arid  usable  * " ^ pr0duct,on  rule*  a"d  the 
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ded,i  cal  ”ake  be  sei,-de,ea,in8i  *°°  "'PTh 

and  depth  of  such  attempts  suggest  that  flexibility  shn  id  k fu  ebuS8Mg  programs.  The  diversity 
-ve  that  a program  ,s  cprracf  Ihe  dT^  ZZ^'Z^ZZ  S 


wuiibiaer 


things:  how  well  the  program 'Ts 'u’Srsto^  hnTTrd  T T®  program  can  depend  on  many 
components,  how  many  checkout  attempts  have’been  made ' ek  Fo*  ^ i'S  °!  C6rta,n  pr0gram 
be  considered  statements  of  expectations  for  the  *'  ^ '°"°^  ca" 
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1.  (The  program  halts) 

2.  (The  MOVE  event  Is  entered) 

3.  (JOE  MOVES  3 AND  1) 

4.  (JOE  MOVES) 

5.  (JOE  ROLLS  3)  (JOHN  ROLLS  1)  (JOE  MOVES) 


6.  'GENSEQ  entered)  (COMPARE  entered)  (MOVE  entered) 

All  are  valid  expectations  and  can  be  useful  at  various  phases  of  the  program’s  development.  The 
second  might  correspond  to  a state  where  the  staff  of  the  game  is  considered  checked  out,  while  the 
fifth  represents  a full  observation  of  the  external  events.  The  point  is  that  any  level  of  detail  should 
be  possible  for  stating  expectations. 


The  system  supports  this  position  by  providing  a TERMINAL  primitive  for  this  purpose.  The 
sequential  collection  of  TERMINAL  Outputs  constitutes  the  list  which  must  match  the  intention  string. 
In  Figure  3 the  rule 

FIRST-MOVE  :=  (TERMINAL  PLAYER. -1  ’MOVES') 

has  this  TERMINAL  event.  An  intention  siring  for  this  program  segment  would  therefore  be  (JOE 
MOVES).  If  the  intention  string  is  to  be  (JOE  ROLLS  3)  (JOHN  ROLLS  1)  (JOE  MOVES),  then  the  rule 

ROLLDIE  :=  (GENMEM  DIEVAL) 

could  be  changed  to 

ROLLDIE  (GENMEM  DIEVAL)  -> 

(TERMINAL  PLAYER.-l  ’ROLLS’  DIEVAL.-l) 

Again,  the  level  of  detail  depends  upon  the  placement  of  the  TERMINAL  events. 


By  treating  expectations  this  way,  XREP  C3n  be  used  as  a parser;  the  intention  string  is  the 
input,  the  TERMINALS  guide  the  parsing.  The  production  system  is,  of  course,  a perfect  vehicle  for 
carrying  out  this  analysis;  many  production  systems  are  used  in  some  kind  of  parsing  operation.  The 
nondetermmistic  behavior  of  a production  system  finds  a successful  path  though  the  rules,  while 
masking  false  attempts. 


Another  observation  about  the  intention  string  mechanism  keeps  it  in  proper  perspective.  The 
ability  Jo  state  program  expectations  is  a tool  to  aid  in  verifying  programs,  yet  the  intention  string 
has  a test-case"  flavor  with  little  formal  basis.  As  a result,  when  a program  ma.  nes  a particular 
string,  little  more  can  be  said  other  than  the  program  matched  that  particular  intention  string.  While 
certainly  no  basis  for  proof,  a successful  parsing  does  have  some  measure  of  correctness  to  it. 
Dijkstra  said  that  this  process  "can  be  used  to  show  the  presence  of  bugs,  but  never  to  show  their 


L J 


AN  INTRODUCTORY  EXAMPLE 


absence!  (in)  Though  true,  that  statement  does  not  reflect  how  useful  that  detection  can  be  in 
debugging  errors.  Formal  proof  methods  give  few  indications  as  to  the  cause  of  a failure  when  one 
is  detected.  As  will  be  shown,  the  intention  string  mechanism  provides  a good  environment  for 
detecting  and  correcting  bugs. 


2.6  SUMMARY 


By  analyzing  an  English  example  from  lomatic  Programming  viewpoint,  several  situations 

unique  to  natural  language  and  traditionally  ignored  by  computer  systems  have  been  uncovered.  Not 
only  are  they  a basis  for  XREP’s  language  and  constructs.,  but  they  also  represent  the  focus  for  the 
debugging  algorithms.  The  Automatic  Programming  paradigm  offers  both  a new  framework  in  which 
to  address  representation  issues  and  new  criteria  by  whieh  to  judge  their  adequacy.  This 
dissertation  points  to  human  communication  methods  as  a source  for  its  language  representations, 
while  claiming  that  close  modelling  of  natural  language  problems  plus  the  ability  to  resolve  them 
mef  Ur!nrn  rePresentations’  adequacy  and  worth.  The  hypothetical  role  of  Automatic  Programming 
makes  XREP  theoretical  and  open-ended;  as  a test-bed  for  representational  ideas,  XREP  can  ignore 
the  severe  problems  associated  with  producing  a “closed"  system.  The  results  of  succeeding 
chapters  should  be  viewed  in  this  light. 


(iii)  O.-J.  Dahl,  E.W.  Dijkstra,  and  C.A.R.  Hoare,  Structured  Programming,  ed.  by  C.A.R.  Hoare  (New 
York:Academic  Press),  1972,  page  6. 


3.  TIIE  PRODUCTION  L1NCU/1GE  - Pl.X 


3.1  PRODUCTION  SYSTEMS  IN  CENER/ll. 


?vr)pmt  6 derivat,on  of  a computer  program  from  an  English  statement  by  Automatic  Programming 
f/np?  rel'Jires  a diversity  of  expertise  which  starts  with  understanding  and  representing  natura 
language  and  concludes  wh  debugging  and  proving  the  correctness  of  the  generated  program 


svstem  inH \u  ^ P C*  m mteractive  environment,  then  both  the  Automatic  Programming 

system  and  the  user  must  have  a target  to  provide  direction  to  any  discussion.  That  target  is  the 

d,a°ogum  8 Sener3ted:  thuS  Uie  Pr°S1-3mm.ng  language  is  the  vehicle  of  the  process  acquisition 


lananJ  °'  °Ur  pr02ramrtlil1S  language,  PLX,  thus  rests  on  its  central  role  as  the 

language  ,n  which  the  users  program  (after  translation)  is  stated  and  the  system’s  understanding  is 

DrODe'rties'o  t 7|na‘Ur  " be  deCigned  f°  refleCt  the  handlin5  °f  variables  and  structural 

arise  n J ! lan3uaSe  a maintainable  manner,  and  to  address  the  computing  issues  which 
arise  in  understanding  programs:  what  computer  resources  are  needed  during  execution  how 

u s e r ’s  f°  a me  wo  rk)36  reC°rded'  lh'5  reC°rdi"g  can  be  Used  t0  debuS  the  Program  (within  the 


Although  our  mam  concern  in  this  report  is  with  the  automatic  derivation  of  commuter 

theTTo  ^ n'u  lan3Ua5e  statements,  we  must  first  develop  a detailed  understanding  of  how 
these  programs  win  be  represented  and  how,  as  we  will  show,  this  aids  in  the  automatic  derivation 
process.  The  worth  of  PLX  thus  depends  not  on  how  well  it  compares  to  other  programming 

facedTv'the  A ^n  T"  p reSP°nd.5  ,0  the  e*Pres5iveness  of  English  and  the  functionality  questions 

PLX  concerns  H r orator  and  debugger.  The  first  step  in  our  evaluation  of 

klx  concerns  the  decision  to  make  it  a production  language. 


P xycholoffic.nl  Considerations 


des,anIhoethaCqUIS'tl0n  °!  Kn0w,ed3e  from  human  protocol  presents  psychological  considerations 
designing  the  appropriate  model  for  that  information.  Justification  of  PLX  as  a production  system  i 

such  grounds  can  only  be  hypothesized  by  investigating  other  works  whose  primary  task  was  tl 
actual  use  of  such  protocols. 
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nra*  'n  ,heir  studV  of  human  problem  solving,  Newell  and  Simon  theorize 
organization  of  human  programs  closely  resembles  a production  system  organization. 


that  the  actual 
As  they  claim, 


A production  system  encodes  homogeneously 'the  information 
information  processing  system  how  to  behave.(i) 


that  instructs  the 


That  is,  no  division 
of  productions  may 


exists  between  program  information  and  program  control  flow  exceot  that  nrrW 
carry  additional  information.  Further,  P * °rder 


In  a production  system,  each  production  is  independent  of  the  others  - a 

.sss.t.  s,sr 

s=s --sr-srcu*:  srxsass^ >• 


toTal  nrnh|Cti0nS,  themselves  seem  to  ^present  meaningful  components  of  the 
total  problem  solving  process  and  not  just  odd  fragments.(iii) 

i^prerurbrco»p,e7e  "*  ^ °'  3 pr0duc,i°"  rule  *•"««•»  • coherent 

svs...  can  use  a production  rute  i a 


Waterman  and  Newell  ^"ttrtr'pAS-n*  'in  it'  V'0'0,1  ana'ysis  done  by 

derived  by  the  subject  The  Dsv-hnlna'  i #P  m de'S  the  acquisition  of  a new  piece  of  Knowledge 
sterna  4yan,  ^ 


The  DENDRAL  work  ([BUCHANAN  69],  [BUCHANAN  711  rBUCHAI\IAN  791  ».  . . 

another  study  which  uses  a nroHurtinr,  ewei  \ miv  / i j,  (HUUHANAN  72],  among  others)  is 

•nos  to  ftnd  ch™re.r,!r«t^t  12" ZZ?  7 ."f'  i,s  Kn0*ledee  ba«-  DENDRAl 

originally  hand  coded  from  dialogues  with  chemistry  eToTrls"  heuns,ics  which  were 

a production  system  as  situation-action  mice  i J Per,s-  Later.  these  ideas  were  encoded  within 
flexibility  gamed  is  used  to  the  authors'  advantage  ”P  'he°ry  'r°m  'he  pr°eram'  The 


804*’  NeWe"  3nd  H'A'  Simon'  PrM""'  Solving.  New  Jersey:  Prentice-Hall,  1972,  pg, 

(n)  Ibid. 

(mi)  Ibid. 
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li,,le  ac,ual  '•eP'-ogramminE.  This  allows 

S I?-.  ‘a,rs  0 rlh  di"erent  va,sions  01  lhe  ,he°'V.  • very  useful 
feature  when  dealing  with  a subject  as  uncodified  as  mass  spectrometry.(iv) 

DENnRA|enrAoUf0matlC  ,P/0graTinS  probiem  is  similar  t0  the  protocol  analysis  of  PAS-II  and  the 

°e  ?he  LPu?  k ThJ"l  6 , ,d  °ris;i’31  da,a  11  S,ar,S  Wi,h  a"d  ,ha  °<  the  finished  product, 
natural  i P ° h?  [ a process  whos>e  structure  must  thereby  be  inferred  By  dealinp  with 

dialogue  SSing  XrTp's  de^T^  C.°ntend  W‘th  the  fragmented  nature  of  human 

above  quotation  is  a*, so  Th“S'  lhd 


f1  unrtionnl  Considerations 


the  p^du^Honb^a^guao^o^^XRH*0^  Tte'T  *£*“}*"  W.a.s  meant  to  give  some  intuitive  basis  for 
ro  „ . gufue  0 XRtPi  'be  functional  considerations  have  direct  impact  on  this 

zs.r.“..7,:r,  « *• 


H i U d be  measured  by  the  auxiliary  benefits  gained  by  a particular  notation  In  vrfp’ 

Xe"yhoVproC^iodn^r;,Wh,Ch  ^ wl“  - *•"  ^ o,  .hi! 

r.BrJlthlS  * 0gram.  f0r  du,0matins  the  learning  of  heuristics,  Waterman  used  production  rules  for 
froTth.  n * Cla,ming  that  thlS  represe"tation  technique  "permits  separation  ort^heur^Hcs 
with  gener SXS*  ^ti,ication  °f  the  individual  heuristics,  and  is  compatible 

rules, ^n ”*"*  °n  "*  ,h~*  b*  'he  Production 


work  T'Z  rntird  ^ the  PreVi°US  subsection  is  the  vehicle  for  Waterman’s  latest 

LWA I ERMAN  74].  Again,  the  nature  of  production  systems  aids  his  analyses. 


ArtifidaMnBtenlilTan’  *4.  Su*ter‘an*  and  EA  peigenbaum,  "Rediscovering  some  Problems  of 

mJ  tzer JnTn  8i  h-  7n  U rXt  0f  °rganiC  Chemistry."  Machine  Intelligence  5.  Ed.  by  B 
Meltzer  and  D.  Michie  (Ed'nburg:  Edinburgh  University  Press),  1969,  pg.  274.  X 

1C™  beaming  o,  Heucisfics." 
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A different  study  used  a production  system  to  represent  inference  rules  for  natural  language 
relations  [LINGARD  72],  Lingard  and  Wilczynski  used  a Backus  Normal  Form  (BNF)  representation  for 
stating  the  interaction  between  relations.  Thus  a rule  like  "GF  ->  F F"  could  represent  the  fact  that 
<GF>  IS  the  fa,her  of  the  father-  Their  system  could  accept  requests  like 
(Sum  ?Frn?S!  a"d  deduce  ,ts  trufh  bY  usinS  the  grandfather  rule,  and  the  two  assertions 
(JOHN  F FRED)  and  (FRED  F JOE).  By  representing  the  relation  interactions  this  way,  a uniform 
parsing  algorithm  could  be  used  to  carry  out  the  analysis  within  an  associative  data  base.  In  his 
Ph.D.  dissertation  Lingard  continues  that  investigation  [LINGARD  75], 


vDcJde  mspecfab,llty  and  accessibility  of  production  rules  are  the  main  issues  of  this  discussion. 
Ps  debugger  is  to  function  effectively,  it  must  work  on  a representation  that  is  responsive  to 
the  requests  which  might  be  made  of  it.  In  Chapter  5,  the  scope  of  information  needed  by  the 
debugger  will  emphasize  these  points. 


Other  functional  benefits  of  the  production  language  will  be  discussed  later  in  Chapter  5 and 
Section  3.5  when  enough  of  XREP  has  been  detailed  to  adequately  state  the  claim.  The  rest  of 
the  section  is  devoted  to  PLX,  its  environment,  terminology,  and  primitives. 


3.2  THE  PROGRAMMING  ENVIRONMENT  FOR  PLX 

The  production  language  character  of  PLX  comes  strictly  from  its  control  flow  behavior.  The 
esign  of  its  other  facilities  was  influenced  more  by  the  environment  in  which  PLX  was  programmed 
than  by  classical  production  language  issues.  To  put  the  capabilities  of  PLX’s  primitives  in  the 
proper  perspective,  that  environment  will  be  described  first. 


rQAi  7rXnRE7P,  JS  written  in  INTERLISP  using  the  data-base  extensions  of  the  API  language 
UAUER  74a].  API,  a LISP-based  pattern  match-language  of  the  PLANNER(vi)  generation,  is  tailored 
for  the  Automatic^ Programming  project  at  the  USC  Information  Sciences  Institute.  The  properties  and 
pecu  larities  of  API  will  not  be  detailed  here;  only  the  facilities  borrowed  from  it  will  be  considered. 


The  data  base  is  associative;  information  is  stored  as  tuples  whose  first  item  is  the  relation 
which  associates  the  others,  in  either  a positional  or  keyword  manner.  Any  item  of  a tuple,  including 
e relation,  can  itself  be  a tuple.  Neglecting  the  question  of  variables  and  literals  for  the  moment, 
all  the  following  are  legitimate  entries: 


(FATHER  FRED  BOB) 

(BETWEEN  BOTTLE  (CHAIR  TABLE)) 

(PARAMETER  ROUTINE  A B (C  D)) 
((COMPOUND  RELATION)  X Y) 

(KEYRELATION  (KEYWORD  1 X)  (KEYW0RD2  Y» 

(KEYRELATION  (KEYW0RD2  Y)  (KEYWORD  1 X)) 


(vi)  See  [80BR0W  74]  for  a review  of  this  generation  of  Al  languages 
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The  Isst  .wo  are  equivalent  examples  of  keyword  tuples.  The  ambiguity  of  which  type  of  relation  is 
which  U'nce  they  all  look  the  same)  is  resolved  by  forcing  each  relation  to  fall  into  disjoint  classes, 
either  positional,  keyword,  or  function  (described  below).  So,  in  the  examples,  if  KEYRELATION  is 

declared  keyword,  the  last  two  tuples  are  the  same.  If  KEYRELATION  is  positional,  then  they  are,  of 
course,  different. 


Each  tuple  is  assigned  a unique  name  and  stored  in  a named  context  given  in  its  assertion. 
Ihese  conlexts  can  be  hierarchically  organized  for  retrieval  purposes  and  are  under  user  control. 

l he  contexts  effectively  segmenl  the  data  base  into  isolated  sections,  while  the  context  hierarchy 
joins  the  sections  as  the  user  wishes. 


Another  important  feature  of  API  comes  from  allowing  i s predicates  and  patterns  to  consist 

of  an  arbitrary  mix  or  LISP  functions  and  API  expressions.  For  example,  FS*  is  an  API  function 
whose  form  is 


(FS*  <variable>  <pattern>) 

This  function  matches  the  puttern,  but  returns  the  value  of  the  variable  mentioned.  In  this  sense 
1-5*  acts  as  a selector  function  based  on  the  variable  in  the  pattern.  Thus 

(FS*  NUMBER  (AGE  NUMBER  BOB)) 

says  to  find  a NUMBER  such  that  NUMBER  is  the  AGE  of  B03.  If  the  retrieval  is  successful,  NUMBER 
is  bound  to  the  desired  value,  which  is  then  returned  as  the  value  of  the  FS*  expression  If  the 
retrieval  fails,  the  returned  value  is  NIL,  the  false  atom  of  LISP. 


Another  possible  expression  is 

(FS*  NUMBER  (AND  [WIDTH  NUMBER  B0ARD][GT  NUMBER  10])) 

whose  interpretation  is  to  find  a NUMBER  larger  than  10,  which  is  also  the  WIDTH  of  a BOARD  This 
exampie  shows  a mixing  of  an  API  expression,  (FS*  . . .),  two  LISP  predicates,  (GT  . . .)  and  (AND  . . .) 
and  an  API  tuple,  (WIDTH  ..  .).  This  marriage  permits  a great  deal  of  power  and  convenience  by 
allowing  the  user  the  expressiveness  of  both  systems  without  restricting  him  to  either. 


3.3  PREI.IMIN/IRY  TERMINOLOGY 


The  following  terminology  appears  throughout  the  description  of  PLX.  Though  some  of  the 

terms  nave  been  used  before  in  a loose  manner,  they  will  now  be  linked  more  closely  tc  the 
production  language. 
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An  event  is  either  a simple  or  a compound  event. 


A simple  event  is  an  atomic  element  to  be  used  as  a nonterminal. 


• A compound  event  is  either  (1)  a parenthesized  expression  who-e  f.rst  element  is  a 
system  primitive  or  (2)  an  expression  with  events  separated  by  or 


• A node  IS  either  a simple  event,  a type  2 compound  event,  or  the  result  of  executing  a 
type  1 compound  event.  It  has  the  following  properties:  (1)  it  can  only  have  one 
ances.or  and  (2)  all  generated  offspring  must  be  new  nodes  (hence  no  loops). 


• A typed  variable  is  a type  together  with  an  identifying  expressicn  (separated  from  the 
ype  y a . ).  The  expression  can  be  either  a generation  number  or  a function  which 
points  to  a particular  binding  - for  example,  PLAYER.  1,  and  PLAYER.flNDEX  MAX  DIEVAL). 


• A nenerniion  number  is  an  integer  which  identifies  the  relative  position  of  a variable 
type  in  a particular  path  from  a point  in  the  generation  tree. 


pi  AVMhl!S  P.LAYE1R’2  defines  the  second  player  mentioned  from  some  point,  while,  by 

, 1 re  erS  ° the  last  player  inserted  into  I he  PEG,  PLAYER.-2  to  the  next  to  last 

so  forth. 


convention, 
player,  and 


An  access  path  from  an  event  in  the  tree  is  the  unique  ancestor  chain  of 
nodes  up  to  the  root. 


events  and 


In  defining  what  an  event  can  reference  during  its  execution,  the 
environment  for  any  evaluation  done  by  the  event. 


access  path  becomes  the 
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.3.4  PLX  PRIMITIVES 


The  current  version  of  PLX  has  six  primitives  whose  syntax  and  functional  behavior  will  be 
Riven  here  in  an  informal  manner.  The  next  section  will  give  a formal  description  of  each  primitive 
showing  its  effect  on  the  PEG,  while  at  the  same  time  describing  how  the  event  separators  cause  the 
primitives  io  interact. 


The  form  of  a production  rule  is: 

* 

<parent-def-name>  :=  <event>  [{,(->}  <event>  ] 

In  other  words,  a valid  rule  is  one  whose  right-hand  side  is  one  or  more  events  separated  by  or 
Besides  simple  events  (i.e.,  nonterminals),  an  event  can  take  on  any  of  the  following  forms: 

(GENMEM  type  API -predicate  next-event) 

(GENSEQ  type  APl-predicate  next-event) 

(COND  APl-predicate) 

(INSERT  type.APl-expression) 

(TERMINAL  API -expression) 

(FUNCTION  API -expression) 

The  GENMEM  event  given  by 


(GENMEM  type  APl-predicate  next-event) 

binds  a local  variable,  making  it  the  "generation"  point  for  "next-event."  The  value  of  the  variable  is 
chosen  from  the  global  data  base  by  the  API  request 

(LOCAL  (ENTITY) 

(MATCH  (AND  (AMO  ENTITY  type) 

APl-predicate  ))) 

LOCAL  is  an  API  function  which  creaies  local  variables  --  in  this  case  only  ENTITY.  MATCH  is 
another  API  function  which  tries  to  match  the  pattern  given  — in  this  case 

(AND  (AMO  ENTITY  type)  APl-predicate).  The  pattern’s  interpretation  is  to  find  an  ENTITY  such  that 
ENTITY  is  a member  of  (AMO)  the  set  "type”  while  also  satisfying  the  APl-predicate.  The  presence 
of  the  APl-predicate,  ignored  in  the  example  of  Chapter  2,  acts  as  a filter  between  the  data  b:se 
and  the  potential  values.  So,  for  example,  if  the  data  base  has  the  following  assertions: 

(AMO  1 DIEVAL) 

(AMO  2 DIEVAL) 

(AMO  3 DIEVAL) 

(AMO  4 DIEVAL) 

(AMO  5 DIEVAL) 

(AMO  6 DIEVAL) 
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then 


(GENMEM  D1EVAL  T (->  NEXT)) 


will  pick  any  of  the  DIEVALs,  while 

(GENMEM  DIEVAL  (EVENP  ENTITY)  (->  NEXT)) 

will  consider  only  the  values  2,  4,  and  6,  since  EVENP  is  a LISP  predicate  which  tests  for  the 
"evenness"  of  a number.  In  either  case  an  appropriate  DIEVAL  is  chosen  and  assigned  to  DIEVAL.  1 if 
this  is  the  first  DIEVAL  to  be  bound,  DIEVAL.2  if  this  is  the  second,  and  so  on.  Execution  of  NEXT 
follows  this  binding  process. 


The  effect  of  the  GENMEM  statement  is  to  produce  a variable  which  is  local  to  the  current 
path  of  the  program.  In  many  production  systems,  all  actions  depend  on  a global  data  base;  there  is 
no  notion  of  local  variables.  In  PLX,  the  typed  variables,  as  generators  for  future  events,  act  as 
locals,  a feature  which  gives  XREP  the  capability  to  contend  with  questions  about  data  structuring. 


Once  the  binding  takes  place,  "next-event"  is  executed.  If  some  failure  occurs  later, 
backtracking  may  return  processing  to  the  GENMEM  for  selection  of  a different  value,  making 
GENMEM  a "choice  point"  in  the  execution  of  a program. 


The  GENSEQ  event  given  by 

(GENSEQ  type  API -predicate  next-event) 

has  the  same  action  3s  a GENMEM  event,  except  that  all  values  of  "type"  which  satisfy  the 
API -predicate  are  chosen,  each  of  which  is  to  be  followed  by  "next-event."  The  effect  is  like  having 
n independent  (i.e.,  no  interaction)  GENMEM  events,  where  n is  the  number  of  values  which  pass  the 
APl-predicate.  The  GENSEQ  is  not  meant  to  model  a loop,  but  instead  models  a structure  of  disjoint 
actions  which  would  otherwise  be  difficult  to  represent. 


(COND  API -pred)  is  a predicate  event  which  acts  as  a filter  to  the  current  production  rule. 
When  a COND  event  is  encountered,  it  is  evaluated.  If  its  result  is  NON-NIL,  the  processing  proceeds 
normally.  If  it  results  in  NIL,  then  a FAILURE  is  detected  and  processing  backs  up  to  the  last  choice 
point:  a GENMEM  or  a rule  choice  (to  be  explained  in  page  43). 


If  COND  is  the  first  event  on  the  right-hand  side  of  a production,  the  effect  is  very  close  to 
the  situation-action  pairs  of  the  production  systems  found  in  DENDRAL  and  PAS-II,  or  the 
pattern-invoked  procedures  of  PLANNER.  That  is,  a rule  is  chosen  and  acted  upon  if  the  situation 
(COND)  matches.  The  generality  of  APl-predicates  gives  the  COND  event  arbitrary  testing  power. 


(INSERT  type. exp)  is  an  event  used  to  "find"  a specific  typed  variable  bound  in  a preceding 
event  and  to  reinsert  it  into  the  local  context.  A GENSEQ  or  GENMEM  must  be  an  ancestor  of  the 
INSERT  and  the  search  for  "type.exp"  must  be  successful.  The  expression  "exo"  is  arbitrary  and 
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□i^a Lri-f a Valld  interPretalion-  '-e-,  it  must  point  tu  a specific  bound  instance  of  "type.”  If  no 
HLAYER  has  been  bound  in  either  a GENSEQ  or  GENMEM,  then 

(INSERT  PLAYER.<anything>) 

is  erroneous.  The  effect  of  the  INSERT  is  to  reinsert  the  typed  variable  into  the  PEG  (without  giving 
it  a new  generation  number)  for  future  references. 


(TERMINAL  API -exp),  by  evaluating  APl-exp  and  "outputting"  the  result,  acts  as  the  program’s 
interface  to  the  outside  world.  If  XREP  is  in  a monitor  mode,  then  the  collection  of  TERMINAL  event 
computations,  in  the  order  of  their  occurrence,  must  match  the  given  intention  string. 


(FUNCTION  APl-exp)  evaluates  APl-exp  for  its  effect  only.  Since  the  control  structure  of  PLX 
includes  automatic  backtracking  for  certain  failures,  the  effects  of  FUNCTION  may  need  to  be  undone. 
However,  due  to  the  anticipated  frequency  of  FUNCTION  events,  state  saving  prior  to  execution  may 
be  impractical.  The  solution  involves  the  use  of  API  contexts  and  a policy  decision.  Each  FUNCTION 
statement  is  given  a new  API  context,  linked  hierarchically  to  existing  ones,  in  which  to  make  any 
new  assertions  that  affect  the  state  of  the  world.  If  this  event  is  then  to  be  eliminated  by 
backtracking,  then  XREP  needs  only  to  remove  its  context  from  the  hierarchy  to  undo  all  its  effects. 
As  long  as  the  event  has  not  changed  any  globals,  its  removal  will  be  clean. 


.1.5  FORM /IL  DESCRIPTION  OF  PLX 


A formal  descriphon  of  PLX  will  be  given  by  first  viewing  abstract  productions  and  the 
eva  uation  environment  created  by  the  event  separators,  next  reviewing  the  control  flow  of  the 
producf'on  language,  and  then  showing  how  each  primitive  maps  into  the  PEG.  When  the  semantics 
of  PLX  are  defined  in  terms  of  the  PEG,  the  description  of  the  language  becomes  operational,  giving  a 
firm  interpretation  to  any  construct  while  also  making  any  structural  changes  to  the  PEG  during 
debugging  immediately  relatable  to  the  language. 


/Ih&tmct  Productions  mid  Event  Sopomtors 


The  right-hand  side  of  a production  was  shown  to  be  a sequence  of  events  with  event 
separators,  either  ","  or  between  each  pair.  The  event  separators  affect  the  evaluation 
environment  of  any  event,  a concept  to  be  detailed  in  Chapter  4.  Now  they  will  be  analyzed  for 
their  impact  on  the  PEG  and  Access  Graph  only. 


Figures  8 and  9 show  the  simplest  rules  involving  an  event  separator.  In  Figure  8 the 
between  B and  C means  that  B is  protected  from  C,  reflected  in  the  Access  Graph  by  having  B and  C 
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on  separate  branches  from  A,  and  in  the  PEG  by  making  B a rectangular  event(vii).  The  evaluation 
environment  for  an  event  consists  of  the  global  data  base  plus  all  the  information  in  its  access  path. 
In  the  Access  Graph  an  event’s  access  path  is  obvious,  consisting  of  all  events  "above"  it.  In  the  PEG 
the  access  path  is  not  so  clear,  since  each  right-hand  side  produces  a single  level  under  its  father; 
the  structure  explicit  in  Ihe  Access  Grapn  is  implicit  in  the  PEG.  Chapter  4 will  show  how  to  derive 
access  paths  f'om  the  PEG.  For  the  purposes  of  this  chapter,  look  at  the  Access  Graph  when  this 
information  is  necessary. 


In  Figure  9,  B is  viewable  to  C,  because  "->"  separates  the  events.  Thus  C is  under  B in  rhe 
Access  Graph,  and  B is  oval  in  the  PEG.  This  configuration  means  that  C has  access  to  everything 
generated  by  B,  a situation  which  is  obscured  in  the  Access  Graph,  since  it  looks  as  if  B has  already 
done  its  work  by  generating  C.  However,  the  PEG  clarifies  this  misconception  by  showing  that  B can 
still  generate  information,  since  it  is  currently  an  unopened  leaf  of  the  tree. 


Access  Graph  PEG 

Figure  8.  A :»  3 , C 


C 


Access  Graph  PEG 


Figure  9.  A 3 ->  C 


(vii)  Since  the  rightmost  event  in  the  PEG  has  no  "brother"  successor,  its  shape  is  immaterial. 
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Figure5  10  through  13  show  all  the  possible  productions  with  three  events  in  the  right-hand 
Side  of  the  rule.  Again  notice  in  the  PEG  that  one  production  rule  results  in  one  level  under  the 
rather  The  PEG  construction  for  a production  is  trivial;  write  down  all  the  events,  if  follows  one 
make  it  rectangular,  otherwise  make  it  oval  (this  accounts  for  the  fact  that  the  last  event  is  always’ 
ova!,  since  no  event  separator  follows  it).  The  construction  of  the  Access  Graph  is  not  so  obv.ous, 
though  still  not  difficult.  The  algorithm  is  as  follows: 


Write  the  first  member  of  the  right-hand  side  under  the  left-hand  side 
nonterminal. 


2.  For  each  successive  (event-separator  event)  pair,  if  the  event  separator  is 

then  write  the  event  down  as  a new  branch  under  its  predecessor’s  father;  if  the 
event  separator  is  then  write  the  event  under  its  predecessor. 

For  example,  in  Figure  12,  B is  written  under  A according  to  step  1.  Next  the  pairs  (->  C)  and  (,  D) 
are  considered  in  order  as  stated  in  step  2.  Since  "->"  precedes  C,  C is  written  under  B.  Then, 
since  precedes  D,  □ is  written  as  a new  branch  under  the  father  (B)  of  its  predecessor  (C) 
resulting  in  the  desired  tree. 


Access  Graph  PEG 

Figure  10.  A :=  B , C , D 


D 

Access  Graph 


PEG 


Figure  13.  A ■.=»  B , C ->  D 


« 


,,  ,4'8U,reS  4 and  15  n|C,ure  tw0  Access  Graphs  still  unaccounted  for.  Conceptually,  they  can  be 

ought  of  as  representing  the  production  rules  given  in  their  associated  figure.  However,  no 
con  iguration  of  the  PEG  can  account  for  the  parenthesized  expressions  (B  ->  C)  or  (3  , C),  called  a 
ype  2 compound  event  in  Section  3.3,  while  stili  maintaining  the  conventions  that  each  production 

adds  just  one  level  to  the  PEG.  The  problem  is  fortunately  not  important  and  is  circumvented  by 
forcing  rules  like  7 


A :=  (B  ->  C)  , D 


to  be  rewri‘ten  as  the  pair 


A temp  , D 
temp  :=  B ->  C 

This  transformation  has  no  substantive  effect  other  than  to  add  an  extra  nonterminal  in  the  Access 

Graph  and  introduce  another  level  in  the  PEG.  For  this  reason  type  2 compound  events  will  not  be 
considered  further. 
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Figure  14.  A :=»  (B  , C)  ->  D 


Figure  15.  A :=*  (B  ->  C) , D 
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PEC  Mapping  of  Pl.X’s  Primitives 


The  GENMEM  event  given  by 

(GENMEM  type  APl-pred  next-event) 

produces  the  structure  shown  in  Figure  16.  The  generation  number  n assumes  that  n-1  occurrences 
of  "type"  exists  in  the  access  path  of  this  GENMEM.  A member  of  the  set  "type,"  "vali"  satisfies  the 
APl-pred.  If  no  type  is  found,  then  this  event  fails,  leading  to  backtrack.  If  a GENMEM  is  backed  on 
to,  a new  value  of  "type"  is  picked. 


The  GENSEQ  event  is  given  by 

(GENSEQ  type  APl-pred  next-event) 

results  in  the  structure  of  Figure  17.  The  generation  numbers  start  at  n,  as  in  the  GENMEM  event, 
and  end  at  n+m-1,  where  m is  the  number  of  the  vali  which  satisfy  the  APl-pred.  The  bindings  are 
rectangular,  since  each  branch  is  to  be  independent  of  one  another  --  a situation  visually  apparent 
in  the  Access  Graph. 


The  INSERT  primitive  given  by 

(INSERT  type.APl-exp) 

has  the  simple  structure  of  Figure  18.  The  form  "type.number-value"  reflects  the  generation 
number  and  the  value  of  the  found  "type."  If  type.APl-exp  does  not  point  to  a unique  binding,  this 
statement  fails  and  backup  takes  place. 


The  TERMINAL  primitive  given  by 

(TERMINAL  API -exp) 

is  seen  in  Figure  19.  The  "result"  of  evaluating  APl-exp  is  inserted  into  the  PEG  for  future  | 

reference. 


The  other  two  primitives,  FUNCTION  and  COND,  add  nothing  to  the  PEG  other  than  their  n.me, 
since  they  exist  for  their  immediate  effect  only. 


AO 
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INSERT 


INSERT  ^ 


type. number  = value 
Access  Graph 


[type,  n 


umber  * val 


uej) 


PEG 


P'gure  18.  Graph  structure  for  an  INSERT  event 


TERMINAL 


t 

result 

Access  Graph 


PEG 


Figure  19.  Graph  structure  for  a TERMINAL  event 


Control  Flow  in  PLX 


the  execution  of  the  p^o^a^grJ^n  l^ChTpVr  *2*  %•***?  PEG'  001,1  b*  descnbed  by  tracing 
procedure  will  be  given  °hap,er  2 F'rst>  a short  of  the  processing 


42 


k. 


THE  PRODUCTION  LANGUAGE  - PLX 

the  peg,  :i^I1S^^0'h,Pr0Sra5XREP  f0CUSeS  0n  ,he  in 

not  yet  been  e,Dan*d  I p y ,U"0pe;e<!  ™ara  th*'  «»  event  is  a nonterminal  which  has 

XPEP  chooses  * W,  n^rEVENT1^  52’ 

thi^rrrj:'"  sr^^r. s 'r e,  p°;r  sei  • ™ 

for  nonterm, nets,  the  other  to,  pictting  ty^T'' «^T l££  °'  'h°'Ce  P°'"'S’  °"e  'n  PiCki"8 


-»S  called  S5LVS  ~ — * 


3)  goCtoR5RtepTc"EVENT  ha&  3 d°WnWard  P°mter-  take  't  and  go  to  step  b.  Othe 


rwise 


b)  If  the  event  is  unopened,  make  it  the  CURRENT-EVENT.  Otherwise  go  to  step  a. 


c)  If  the  event  has  a right  pointer,  take  it  and  go  to  step  b.  Otherwise 


go  to  step  d. 


d>  go3Kto  stepT Ward  P0i0ter  <WhiCh  mUSt  6X,St  °r  Step  C WOuld  n0t  have  failed)  and 


tlie  PEg’sLT bRtNEtXf  'It  d°WnWard  tree  search  for  the  first  unopened  event.  Step  a moves  down 

now  be  traced  ah 5 *’  ^ * ° 6pS  C ^ d m0Ve  Up  and  t0  the  right  The  BACKGAMMON  program  will 
now  be  traced  (the  program  ,s  repeated  for  convenience  with  syntactic  updates). 


BACKGAMMON  START  , REST-OF-GAME 

D^MRn,r  !=  ,^ENSEQ  ^AYER  T (••>  ROLIDIE))  ->  COMPARE 
ROLLDIE  :»  (GENMEM  DIEVAL  T) 

c,n^AsRE  :=  <K'ISERT  pLAYER.(INDEX  MAX  DIEVAL))  ->  FIRST-MOVE 
FIRST-MOVE  :=  (TERMINAL  PLAYER.- 1 ’MOVES’) 
REST-OF-GAME:-... 

Figure  3.  Rules  for  beginning  of  Backgammon 


The  program  starts  with  BACKGAMMON  as  the  CURRENT-EVENT. 


1.  Since  BACKGAMMON  is  a 
nonterminal  the  rule  is: 


nonterminal,  a rule  is  chosen  and  attached  to  the  PEG. 


For  this 


Figure  20  shows  tl 
the  production. 


BACKGAMMON  •=  START  , REST-OF-GAME 
-e  current  PEG.  Notice  that  START  is  rectangular  due  to  the 


which  follows  it  in 
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Figure  20.  PEG  after  step  1 

Application  of  SUPER-NEXT  to  BACKGAMMON  makes  START  the  next  CURRENT-EVENT. 

rule  2’  SmCe  START  'S  3 n0nterminal'  a rule  is  chosen  for  it  and  attached  as  in  step  1 above.  The 

S i ART  (GENSEQ  PLAYER  T (->  ROLLDIE))  ->  COMPARE 
results  in  Figure  21  with  control  passing  to  GENSEQ. 


c 


BACKGAMMC  N 


START 

c 


GENSEG 


Figure  21.  PEG  after  step  2 
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22.  The  SS'ir  t S3SM  "2  lllTt  ^7  7 PCS 

type.  Control  now  passes  to  ROLLDIE  under  PLAYER.  1.  & 'S  'S  6 ""b  mstance  of  thls 


Figure  22.  PEG  after  step  3 


DIEVAU  RSinceIE thV ^GENMEM^  Pr°d^eS  I'6  GE^EM  eVent’  whlch  results  turn  in  a binding  for 
state^of  thedpEGREAYE^' 
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Figure  23.  PEG  after  step  4 


5.  Control  passes  to  COMPARE  which  causes  the  production 

COMPARE  :=  (INSERT  PLAYER.ONDEX  MAX  DIEVAL))  ->  FIRST-MOVE 

S is  :^rer  plx  is  « 


6.  When  control  passes  to  FIRST-MOVE, 


r, 

W 


jw  4jwwi.ii  1 
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FIRST-MOVE  :=  (TERMINAL  PLAYER.- 1 ’MOVES’) 


is  chosen,  passed  to,  and  executed.  Since  INSERT  is  in  FIRbf-MOVE’s  access  path,  PLAYER.-l  (the 
last  player  mentioned)  evaluates  to  JOE,  producing  the  string  "JOE  MOVES”  as  the  result  of  the 

TERMINAL  event.  Figure  25,  now  the  same  as  the  PEG  given  in  Figure  5,  shows  the  result  of  this 
action. 


7.  The  program  continues  by  moving  to  REST-OF-GAME,  where  some  action  presumably  takes 
place,  and  concludes  when  the  original  BACKGAMMON  event  is  crossed,  leaving  no  unopened  nodes. 


Figure  24.  PEG  after  step  5 
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Figure  25.  PEG  after  step  6 


3.6  SUMMARY 


Using  graphs  or  trees  as  a medium  for  describing  various  properties  of  programming 
anguages  has  been  common  in  computer  science  research.  For  example,  the  Vienna  Definition 
anguage  tries  to  formalize  a method  for  stating  a programming  language’s  semantics  by  formulating 
an  execution  tree  and  providing  primitives  for  manipulating  that  tree  [WEGNER  72].  Each  language 
construct  is  then  defined  in  terms  of  these  primitives  and  how  they  affect  the  execution  tree,  so  that 
any  implementation  of  the  language  will  have  a precise  foundation.  The  tree  is  their  mechanism  for 
coordinating  the  entire  formalism.  Similarly,  the  PEG,  by  being  the  structure  which  defines  a 
process,  is  the  coordinating  formalism  within  XREP. 
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In  this  chapter  the  production  language  was  described  by  picturing  each  construct  in  terms  of 
the  PEG;  the  next  chapter  will  study  variables  and  access  issues  from  the  same  viewpoint. 


4.  ACCESS  PATH  THEORY 


4.1  INTRODUCTION 


AcC6SS  pa,hs  hae  keen  mentioned  several  times  In  preceding  chapters,  though  they  were 
underplayed  in  importance.  The  access  path  concept  deals  specifically  with  the  evaluation 
environment  presented  to  events,  i.e.,  what  data  are  available  at  any  point  during  the  execution  of  a 
program.  The  fundamental  position  taken  by  this  study,  that  decisions  should  be  made 
dynamically  at  execution  time  rather  than  statically  at  "compile"  time,  forces  a thorough 
understanding  of  the  execution  model  of'ered  by  the  PEG.  In  this  chapter  the  creation  of  that  model 
will  be  analyzed  from  toe  standpoint  of  retrieving  information  fro-  it,  with  the  emphasis  on  the 
correspondence  between  English  methods  and  those  available  through  XREP.  Studying  the 
generation  and  retrieval  of  oata  permits  the  isolation  of  several  problems  which  could  occur  in  an 
Automatic  Programming  problem  acquisition  phase.  This  chapter  will  uesenbe  the  generality  of 
XREPs  methods  and  the  flexibility  of  the  PEG,  while  the  next  will  show  how  they  can  be  used  in 
debugging  certain  errors. 


An  event’s  access  path  was  defined  m Section  3.3  as  the  unique  ancestor  chain  of  events  and 
nodes  from  it  up  to  the  r00t.  Because  it  contains  ail  the  nonglobal  data  which  may  influence  an 
event  s behavior,  the  access  path  is  the  context  of  the  current  process,  the  structure  wh,ch  contains 
an  relevant  information.  Proper  program  organization  can  be  evaluated  through  an  access  path  goal- 
an  event  should  have  access  to  no  more  or  no  less  information  than  it  needs  to  operate;  and  a 
deviation  in  either  direction  is  a structural  flaw  in  the  program 


This  study  of  access  paths  is  important  to  Automatic  Programming  because  luman  dialogue 
oes  no  contain  the  explicit  structuring  found  in  formal  programming  languages,  but  implicit  clues 
are  found  within  its  addressirg  mechanisms.  By  simulating  these  methods  XREP  trie:,  to  mirror  the 
s ructure  inherent  in  the  original  description.  The  definition  and  use  of  access  paths  in  XREP  enable 
the  freedom  of  English  usage  to  be  reconciled  with  the  rigidity  of  a programming  language. 


4.2  NATURAL  I.ANCUACE  ACCESS  METHODS 


Natural  language  has  three  basic  data  retrieval  methods:  the  unique  name  of  the  desired 
object  is  given,  a oronom.al  reference  is  made,  or  the  object  is  identified  by  type  with  some  limiting 
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etcllrl'most  ^TUTTLET  ^ "*  bb’aCb  J°h"'  «■»  USC, 

redundant  and  set  off  by  comma-  as  nonP^J  . f h d modifier  is  considered  nonrestrictive  or 
clause  (now  called  rest£h“^  ,f  "““V*  t0  the  '^ent.f ication,  the 

r0r  example,  in  the  statement  "USC  which  u o □ n Un  P^rase^  ls  riot  enclosed  in  commas, 
won  the  Rose  Bowl  ,975"  is  Seslrk  iv.  M ^ m,  ,975' is  ' » • clause  "wh,ch 

won  the  Rose  Bowl  ,n  1975  is  or, vale  " the  ...  T"'  ' statement  becomes  "the  school  which 

restrictive.  Since  most  inanimale  oti  eV £ ITJ  'S  '°  iden"^  ,he  object,  hence 

retrieval  mechanism  and  is  the  one  with  which  XPEP  is^nV  ""T’ a * restndlve  clause  is  a 
be  shown  to  be  , special  case  o,  Ihe  restrictive  clause  stota  h™"0"3'  re'ere"Ce  Wi"  'aler 

ll.»ib„:,h;  - *0  -heir  scope  and 

1.  The  last  player. 

2.  The  first  player. 

3.  The  player  who  rolled  a 5. 

A.  John’s  die  value. 

5.  The  player  who  rolled  a die. 

6.  The  die  value  rolled  by  the  last  player. 

7.  The  last  player  before  John. 

8.  The  player  who  rolled  the  largest  value. 

JasVpltlrharmS  thaV 'one"' tiSST*  **  tUtf°nS  where  a P^tieul.r  type,  in  this 
because  a reference  to  "the  piayer"  would  be  amh^™  Vu^  predlcate’  ,lrst  0r  last.  is  needed 
seems  to  be  useful  only  in  identifying  end  points  of  'ftvlf'’  ^ ^Umeri^  character  of  this  predicate 
"the  next  to  last,"  or  "the  third"  arp  nnt  . , ,^p' e 5 meiT,bers.  References  like  "the  second," 

possibility  for  error  ,S  create r for  both  the' 7 ' ^ fr0*  ^ are>  Slnce  ^ 

presented  an  unnumbered  list  to  me  and  asked' tor" a raCe'ver  °f  '"formation.  I,  someone  had 
would  ask  tor  confirmation  of  the Tern  h . °"  'he  S”dh  ilem'  1 susPed  ,ha'  ' 

complex  computations  like  counting  ,o  six  fo,  specifying" "a^bjecf  '3"8U3Se  ^ n°'  °"en  USe 

associated  with  the  oblct^ Examples^  sndl  I I!’*  ?esl,eci  0bject  by  Swing  extra  information 

the  sea-ch,  is  restrict  by  havmg  I fo,  If  die  v'alui  I '°rmer  3 ^ ,he  °“i“<  of 

information  would  be  necessary.  several  Players  had  the  same  number,  more 


nofiCiMhZo  f ,Vha'Ue  “ 'he  °bieC'  both  cases, 

P linkage  is  given  to  help  make  the  proper  association.  In  other  words,  John’s 
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age  could  be  requested  in  a context-free  manner  because  all  humans  have  an  age,  but  not  all  humans 
have  d,e  values.  The  w dity  of  "the  last  player’s  die  value"  depends  on  the  environment  of  the 

explicit  rule’  XR?p? ppc  .,reS°M'0"  w'"  be  based  on  SOme  Proximity  measure  rather  than  some 
explicit  rule.  XREP  s PEG  allows  exactly  these  kinds  of  associations  to  be  made. 


The  Dlayer  in  example  5 is  identified  by  association  with  an  event  as  opposed  to  an  obie  -t  — 

» ! \ffertent  fr0m  any  of  the  Preceding.  However,  notice  that  this  form  has  no 

counterpart  in  traditional  programming  languages. 


the  forme?"  ! f ? ^ typ6S  ° f addres2es  which  replace  the  numeric  kind.  In 

he  ormer  the  last  die  value  might  have  sufficed,  but  its  form  emphasizes  the  player  involved  In 

e?J3  TW?r  P?SUmably  n0t  feasible-  50  a new  context,  John,  is  named  and  objects  are 

erenced  from  this  nev  focal  point.  This  method  is  one  of  a class  of  naming  mechanisms  which  is 
more  e.aborate  and  mere  context-dependent  than  those  found  in  computer  languages. 


The  last  example  is  the  most  difficult  because  of  the  generality  of  the  reference.  It  says  to 
select  a player  based  on  the  result  of  some  function  applied  to  an  object  associated  with  players. 

any  assumptions  must  be  satisfied  before  such  a request  can  be  fulfilled:  what  is  done  if  a player 
has  no  die  value,  what  if  a player  has  two  die  values,  what  if  the  result  is  not  unique?  Again  this 

reques  ,s  Highly  dependent  on  the  context  of  the  inquiry;  each  anomalous  case  must  be  treated 
separ  alGly, 


The  examples  given  cannot  possibly  be  exhaustive,  but 
situations  which  arise  in  natural  language.  Each  case  will  have 
facilities  of  the  production  language. 


are  intended  to  represent  typical 
an  interpretation  in  XREP  within  the 


4.3  ACCESSING  TYPED  VARIABLES  IN  XREP 


Generation  Numbers 


A typed  variable  is  created  in  XREP  through  a GENMEM  or  GENSEQ  event 
variable  is  assigned  to  the  form 


The  value  of  the 


iype.n+1 

where  n is  the  current  generation  number  for  this  type  in  the  event’s  access  path.  The  generation 
number,  defined  in  Section  3.3  as  an  integer  which  identifies  the  relative  position  of  a variable, 
serves  more  as  a convenience  for  the  discussions  than  as  a fundamental  tool  of  the  formalism 
because  high  generation  numbers  are  not  often  used.  As  mentioned  in  the  previous  section, 
accesses  to  a set  of  types  probably  use  numeric  expressions  only  at  the  end  points  — for  example, 
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i 


l 


I 


PLAYER.l,  PLAYER.2,  PlAYER.-I,  PLAYER.-2  — while  accesses  to  the  middle  of  such  a group  most 
probably  name  an  intermediate  target  and  then  give  relative  specifications. 


The  scheme  for  assigning  generation  numbers  is  simple:  for  GENMEM  the  current  number  is 
incremented  for  a type;  for  a GENSEQ  the  numbers  are  incremented  across  the  driving  type.  The 
assignment  in  a GENSEQ  comes  mere  from  intuition  and  convenience  than  from  a strong  logical  basis, 
since  each  of  the  elements  could  be  assigned  the  same  number.  Figure  26  shows  the  GENSEQ  from 
the  BACKGAMMON  game.  On  the  left  is  the  actual  structure:  the  PLAYERS  are  numbered  1 and  2 
(according  to  the  GENSEQ  rule)  while  each  DIEVAL  for  the  GENMEM  is  assigned  1,  since  each  is  the 
only  DIEVAL  in  its  owr,  access  path.  The  structure  on  the  right  of  Figure  26  is  also  possible,  since 
each  PLAYER  is  likewise  the  only  one  in  each  corresponding  access  path. 


GENSEQ 


GENSEQ 


PLAYER.l  — JQE  PLAYER.  2— JOHN  PLAYER.l— JOE  PLAYER.  1— JOHN 


GENMEM 


GENMEM  GENMEM 


GENMEM 


ROLLDIE 


ROLLDIE 


ROLLDIE 


ROLLDIE 


DIEVAL. 1 — 3 DIEVAL.  1 — 1 DIEVAL. 1 — 3 DIEVAL. 1—1 


Actual  Access  Graph 


Possible  Access  Graph 


Figure  26.  Generation  number  example 


A more  ambiguous  s'tuation  occurs  m tne  Access  Graph  skeleton  shown  in  Figure  27.  What 
should  the  last  DIEVAL  be  numbered’  A case  could  be  made  for  2,  3,  or  A A more  complex 
numbering  scheme  involving  extra  indexing  is  also  possible,  but  since  this  situation  is  rare  and  since 
XREP  has  many  ways  to  access  all  the  typed  variables  unambiguously  without  relying  on  the 
particular  numbering  schema  chosen,  this  problem  is  one  more  of  implementation  than  of  substance. 
As  a result  this  and  similar  anomalous  situations  will'  be  downplayed;  the  emphasis  will  be  placed  on 
the  addressing  methods. 


1 
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PLAYER.) 


t 

DIEVAL.2 


DIEVAL.l 


I 


GENSEQ 


DIEVAL.? 


PLAYER. 2 


DIEVAL.2 


Figure  27.  An  anomalous  generation  number  situation 


4.4  RELATIVE  /WbMiSSINC 


One  of  the  claims  made  earlier  in  this  report  was  that  the  language  and  the  PEG 
promoted  a notion  of  spatiality  for  data  items.  That  is,  rather  than  merely  a value,  a variable  also 
has  a referenceable  location  within  the  evaluation  environment.  To  take  advantage  of  this  extension, 
ways  exist  within  the  language  of  access  data  in  a spatial  manner. 


The  basic  method  is  to  refer  to  the  variable  type,  together  with  an  identifying  expression  as 
follows: 


type. expression 

The  expression  may  be  anythmg  that  evaluates  to  an  integer  (other  than  zero),  or  it  may  be  a 
functional  form,  INDEX  or  FIND. 


INDEX  will  be  described  in  the  next  subsection  as  a function  which  inspects  GENSEQ  structures. 
FIND  is  a function  which  specifies  a search  for  a type  whose  position  is  unknown.  Its  form  is 
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type. (FIND  API -expression) 

For  example,  if  a DIEVAL  less  than  5 >s  desired,  the  request  is 

-DIEVAL.(FIND  (LT  DIEVAL  5)) 


Other  examples  will  be  given  later 


For  the  case  in  which  "expression"  of  “type.expression"  evaluates  to  an  inteper,  the 
addressing  interpretation  depends  on  its  value.  If  it  is  positive,  that  precise  typed  variable  ,s  looked 
or  in  the  appropriate  context  patn.  This  is  a standard  access,  no  different  from  traditional  systems 

pi  'IJpd^i5  then  3 'S'atiVe  aCCSSS  'S  defireJ  <r0rn  lhe  point  of  ;his  reference.  For  example,  if 
♦ J ■ ,'S  6 reque6‘-  ,he  ',alue  ^turned  is  the  first  PLAYER  found  in  the  search  up  the  context 

path,  i.e.,  the  last  PLAYER  generated  or  inserted  into  the  PEG.  Similarly,  PLAYER.-2  would  refer  to 
the  second  PLAYER  in  the  search  up  the  tree  (the  next-to-last  player  generated  or  inserted). 


Re.erences  of  the  latter  type  give  the  system  its  heterarchical  flavor;  different  processes 
communicate  in  a nonmerarchical  manner.  Information  is  produced  by  a process  and  exposed  to 
w oever  lias  rights  to  it.  A hierarchy  is  imposed  only  implicitly  by  the  structure  of  the  PEG  in 

dealing  with  the  scope  of  typed  variables.  This  situation  will  al'ow  us  to  reorganize  programs  with 
certain  faulty  retrieval  ai tempts. 


The  negative  generation  number  specifies  an  access  relative  to  a reference  point.  Another 
kind  is  possible  where  the  desired  data  is  referenced  relative  to  other  data.  Its  form  is 

* 

type. exp  FROM  spec  {FROM  spec} 


In  other  word 
FROM,  where 
Thus 


s,  a valid  reference  is  a t/pe.e/p  followed  by  any  number  of  "spec"  separated  by 
spec"  is  either  an  evc-nt  name  or  another  type.exp.  The  list  associates  to  the  right. 


DIEVAL.  1 FRO, VI  PLAYER.-2  FROM  ROLLD'E 

is  equivalent  conceptually  to 


(DIEVAL.  1 FROM  (PLAYER.-2  FROM  ROLLDIE)) 

though  no  parentheses  are  allowed,  since  any  other  structuring  will  not  make  sense.  If  a nonunique 
event  is  named  in  the  access,  the  one  "nearest"  the  current  reference  point  is  used. 


When  a typed  variable  which  precedes  a FROM  has  a positive  generation  number,  it  is  located 

acrz  path  0f  the  Current  re,erence  P°int’  ln  the  above  example,  once 
n _. . » i ' 2 FR0M  RObLD c nas  been  Seated,  DIEVAL.1  specifies  a downward  search  for  the  first 
UltVAL  encountered,  not  something  named  DIEVAL.1.  Motice  that  if  a GENSEQ  structure  (or  any 
compound  event)  is  passed  in  the  "upward"  search  for  PLAYER.-2  FROM  ROLLDIE,  the  followinp 

n?cwAYar^uSearCh  f°r  DIEVAL1  bR  ambiguous,  since  each  branch  of  the  GENSEQ  may  contain  a 
DIEVAL.  The  ambiguity  of  the  situation,  explicit  and  graphic,  is  easy  to  relate  back  to  the  user  as  an 
error. 
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To  further  emphasize  how  the  FROM  reference  works,  some  hypothetical  requests  will  be 
evaluated  in  the  context  of  the  Access  Graph  sKeleton  shown  in  Figure  28.  Each  reference  will  be 
given  followed  by  an  interpretation  of  its  evaluation.  Three  items  should  first  be  reiterated- 
negative  generation  numbers  are  references  up  the  Access  Graph,  positive  generation  numbers  are 
re  erences  down  the  Access  Graph,  and  no  access  strays  out  of  the  context  path  of  the  original 
reference  point.  The  examples  follow. 


1. 


DIEVAL.l 


DIEVAL.2 


EVENTX 


I 


3. 


MEMBER.! 


PLAYER.! 


4. 


PLAYER.  1 


EVENTY 


MEMBER.! 


I 


5. 


DIEVAL.2 


PLAYER. 2 


6. 


PLAYER.  2 


DIEVAL.2 


I 


7. 


MEMBER.  1 


8. 


EVENTX 


I 


9. 


PLAYER. 3 


1 


10. 


EVENT 


Figure  28.  An  Access  Graph  skeleton 
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Reference  point:  EVENT 

Access  request:  PLAYER.-2  FROVI  MEMBER.- 1 

This  reference  is  solved  by  locating  MEMBER.-l,  then  finding  PLAYER.-2  relative  to  it.  MEMBER.-l  is 
found  by  looking  up  from  EVENT  for  the  nearest  MEMBER,  which  happens  to  be  MEMBER.l  of  line  7. 
Using  it  as  the  new  reference  point,  the  new  target,  PLAYER.-2,  evaluates  to  the  PLAYER.  1 of  line  3. 
Note  that  if  the  request  had  been  for  PLAYER.-2  from  EVENT,  the  result  would  have  been  PLAYER.2 
in  line  6. 

Reference  point:  EVENT 

Access  request:  DIEVAL.l  FRQM  PLAYER.-2  FROM  MEMBER.-l 

This  request  is  initially  the  same  as  the  one  above,  with  PLAYER. -2  from  MEMBER.-l  pointing  us  to 
PLAYER.  1 on  line  3.  DIEVAL.l  from  it  means  to  now  search  down  the  access  path  for  the  first  DIEVAL 
found,  in  this  instance  to  DIEVAL.2  of  tine  5.  Notice  that  the  context  path  of  the  original  reference 
point  is  not  left,  hence  there  is  no  ambiguity  about  downward  searches. 


Earlier  it  was  mentioned  that  this  string  of  FROM  references  associates  from  the  right.  It  is 
easy  to  see  why,  if  you  try  to  evaluate  the  above  request  from  left  to  right. 


Reference  point:  EVENT 

Access  request:  PLAYER.  1 FROM  EVENTX 

In  this  request  EVENTX  in  line  3 is  located  (not  the  one  in  line  2),  with  PLAYER.  1 from  it  resultinp  in 
the  PLAYER.3  of  line  9. 


Within  this  framework  the  example  English  references  given  in  Section  4.2  can  now  be 
translated. 

1.  The  last  player. 

PLAYER.- 1 

2.  The  first  player. 

PLAYER.  1 

3.  The  player  who  rolled  a 5. 

PLAYER.- 1 FROM  DIEVAL  (FIND  (EQ  DIEVAL  5)) 

4.  John’s  die  value. 

DIEVAL.l  FROM  PLAYER.(FIND  (EQ  PLAYER  JOHN)) 

5.  The  player  who  rolled  a ale. 

PLAYER.- 1 FROM  ROLLDIt 

6.  The  die  value  rolled  by  the  last  player. 

DIEVAL.l  FROM  PLAYER.- 1 

7.  The  last  player  before  John. 

PLAYER.- 1 FROM  PLAYER.(FIND  (EQ  PLAYER  JOHN)) 
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The  reference  to  "the  player  with  the  largest  die  value"  will  be  examined  in  the  next  subsection. 


Addressing  a GKNSF.Q 


Thus  far  all  the  access  questions  have  ignored  ihe  GENSEQ  node.  Since  it  represents  a 
structure  of  independent  events,  some  mechanism  must  acknowledge  the  coherent  character  of  the 
node.  Basically,  the  GENSEQ  can  be  thought  of  as  being  a set  of  contexts  or  symbol  tables  which 
contain  data.  Thus  a request  from  outside  the  GENSEQ  (but  in  the  same  access  path)  may  wish  to 
get  a "pointer"  to  a branch  (context)  of  the  node  in  order  to  do  some  calculation.  The  INDEX  function 
accomplishes  this  task. 


The  call  to  INDEX  is  • 


maintype. (INDEX  function  subtype  subtype-depth) 

where  "maintype"  is  the  generator  type  of  some  GENSEQ,  "function"  is  used  to  select  a member  of 
the  set  subtype,"  "subtype"  is  some  type  which  appears  in  each  branch  of  the  GENSEQ  in  question, 
and  "subtype-depth"  gives  the  relative  oosition  of  "subtype"  to  "maintype."  The  "subtype-depth" 
defaults  to  one  if  it  is  not  specified.  It  gives,  as  mentioned  above,  a relative  position.  For  example,  if 
it  is  2,  the  located  subtype  satisfies 


for  each  GENSEQ  branch. 


subtype.2  FROM  maintype 


In  the  BACKGAMMON  program,  the  COMPARE  rule  was 

COMPARE  (INSERT  PLAYER.ONDEX  MAX  DIEVAL))  ->  FIRST-MOVE 


The  "maintype"  is  PLAYER,  the  "fund, on"  is  MAX,  the  "subtype"  is  DIEVAL,  and  "subtype-depth"  is  1 
since  it  was  not  specified.  Notice  that  if  each  player  rolled  two  die  and  the  compa>,'.on  was  to  -ake 
place  on  the  second  roll,  the  call  would  be 

PLAYER.ONDEX  MAX  DIEVAL  2) 

In  the  COMPARE  rule  the  segment  PLAYER.ONDEX  MAX  DIEVAL)  tries  to  get  a pointer  into  the  GENSEQ 
node  to  the  player  with  the  largest  die  value.  The  result  of  this  access  must  be  unique;  otherwise  a 
failure  which  leads  to  backup  occurs.  Most  often  INDEX  will  be  used  in  conjunction  with  INSERT  in 
order  to  provide  a context-maintaining  pointer  for  future  references.  The  reinsertion  of  the  found 
type  in  the  PEG  is  implemented  as  an  indirect  pointer  back  to  the  original  binding.  So  Once  INSERT 
has  done  its  work,  a reference  like 


DIEVAL.  1 FROM  PLAYER.- 1 

will  result  in  the  largest  DIEVAL  (just  found  by  the  INDEX  function). 


58 


ife«. 


I 


ACCESS  PATH  THEORY 

The  goal  of  the  INDEX  function  is  straightforward,  but  the  complexity  of  its  parameters  is  not. 
The  decision  to  make  it  work  on  a "subtype"  via  one  "function"  is  arbitrary  but  not  restrictive  due  to 
the  arbitrary  power  which  can  be  programmed  into  "function."  In  any  «.ase  the  situation  is  not 
critical,  since  perspicuity  (not  to  be  underrated)  and  not  capability  is  at  stake. 


n rv/A  A dlfferent  desiSn  Problem  can  be  captured  by  viewing  Figure  29.  What  should  the  result  of  a 
DIEVAL.-2  reference  from  EVENT  be?  This  situation  is  so  obscure  that  the  time  spent  on  it  may  not 
be  worthwhile;  a case  could  be  made  for  any  of  the  first  three.  Most  likely  this  particular  graph  will 
never  exist,  and  if  it  does  a more  specific  access  would  probably  be  made.  In  Section  4.6  a 
precise  formulation  of  access  paths  will  be  given;  this  question  will  be  answered  then. 


DIEVAL.l 


EVENT 

Figure  29.  An  Access  Graph  skeleton 


4.5  THE  ACCESS  PATH  PROBLEM 


A study  of  algorithms  meant  for  humans  (rules  for  games,  directions  for  product  use,  etc.) 
reveals  that  information  tends  to  come  in  functional  packets  without  regard  for  any  structuring 
issues.  In  trying  to  code  such  specifications  for  a computer,  programmers  often  produce  a product 
which  reflecting  diffuse  structure,  global  variables,  uncontrolled  transfers,  all  items  which  Dijkstra 
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deals  with  m his  structured  programming  theory  [DIJKSTRA  72],  His  ideas  present  a unifying  goal  to 
programming,  but  are  not  at  all  natural  for  humans,  programmers  included.  Yet  human  specifications 
do  have  structure,  though  much  of  it  is  implicit.  The  use  of  anaphoric  and  relative  references, 
ellipses,  and  sequential  information  provide  clues  that  human  dialogue  and  descriptions  contain 
structure,  though  perhaps  not  as  formally  as  one  of  Dijkstra’s  structured  programs. 

mainta“  thf  Aut0,"atic  Programming  task.  Assuming  that  one  of  its  goals  is  to  find  and 
mamtam  the  structure  inherent  ,n  the  natural  language  input,  the  access  path  problem  is  to  organize 
ragmented  problem  statement  so  that  during  execution  every  process  has  access  only  to 
re  evant  information  while  maintaining  the  appropriate  sequence  of  actions.  Given  that  goal  some 
general  issues  can  be  discussed.  & 


Heterarchy  versus  Hierarchy 

Automatic  Programming  has  found  its  way  into  the  realm  of  Artificial  Intelligence  because  of  its 

fcundra  nPA^  f-rt0  Tn'CharaCtr'  ^ br'nSS  ^ 11  3"  <he  letilnic*ue5  and  desii"  issues  normally 

eorlint^t  11  Lm  '8enCe’  heUnS,lCS-  search-  representation,  etc.  Program  organization,  as  a 
representation  problem,  is  one  or  these  concerns. 

dn<iraw0StnCt’  ^ Wh'Ch  defines  3 structured  program  may  not  be  realistic  or  even 

desirable  as  a target  fer  preliminary  programs  generated  by  Automatic  Programming  due  to  the 

th°:h;rra;Cb:Cal  na  urp  ° the  human  mput'  The  heterarchical  ideas,  mentioned  in  Section  2.3,  offers 
the  flexibility  necessary  in  the  initial  translation  attempt.  In  this  framework  control  is  diffuse 

™Safe  a,Ct'Vfted  !n  a g°a|-°nented  manner  based  on  the  state  of  the  computation,  while  its 
data  exists  and  is  found  as  needed. 

featurfA^AP  tBfLZER theSe  system  ideas  in  a simple  card  piling  environment.  Its  basic 
comes  from  the  interface  between  a routine  and  the  data  base.  In  CASAP  a process 

the  d^t  S b°me  m °rmatl0n’  wi,h  the  interface  trying  to  find  it,  thus  centralizing  the  knowledge  about 


h.w^il16!  th3t  TUCh  flexibility  is  needed  IS  open  t0  question.  XREP  takes  a middle  position 
, , ,n  6 extremes  of  heterarchy  and  hierarchy  by  offering  a nonprocedural  control  flow, 

yet  addressing  data  access  and  scope  issues. 


Nonprocedural  Control  Flow  in  XRKP 


COntro1  ow  ln  XREP  is  determined  by  the  production  system  character  of  PLX,  organized 
"°!  Proc®du^al  y oriented.  The  segmented  nature  of  production  rules  are  like  procedure  or 

tln  rl  T Ca  %bu  w'th|0ut  a f0,mal  Parameter-passing  mechanism.  This  model  has  two  purposes: 
to  provide  a control  which  can  be  easily  monitored  and  understood  and  at  the  same  time  to  allow  the 
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freedom  and  flexibility 
come  at  the  expense  of 


gained  by  giving  up  formal  parameters, 
requiring  all  data  to  be  global. 


ACCESS  PATH  THEORY 
These  qualities  do  not,  however, 


/lrcfiss  and  Sro/jp  of  Data 


By  generating  data  and  inserting  it  into  the  PEG,  GENMEM  GENSEO  and  iwqfrt  . ♦ 

evaluation  environment  tvniral  nf  ai  mi  i;u  t ,,  , 1 and  INSERT  create  an 

capability  Instead  Ly  III.  ALGOL- ike  lanSuaSes.  Most  production  systems  do  not  have  this 


Dptrrmininpf  Across  Paths 


has  somenCba!ise l^*teS7the“ Tple'r's IrMuLg oHI*  » bi"di"SS  n^6'  *REP 

KS^^W^SSSESiF® 


The  access  path  is  the  fundamenta 
Thus  far  only  the  Access  Graph  has  been 
the  formal  methods  of  determining  them. 


I concept  behind  most  of  the  debugging  efforts  of  XREP 
given  for  viewing  access  paths.  The  next  section  will  give 


i*  COMPUTING  ACCESS  PATHS 


emphalL'^emdiilerenc  l VnoTVnf ^ "°deS  wdre  "’e",i0"ed  in  >° 

interpretation  when  calculating  access  paths  in'  thT PEG  ^"o  °l  * ^ 3 $imple 

when  viewing  the  Access  Graph.  " n y a s ightly  more  complicated  one 


eyenlsTahreAboxad  inToMod  5ame  * 'ha'  Fisu,e  4 e’‘ceP'  ,ha'  lhe  compound 

== 


COMPARE,  GENSEQ-NODE,  START,  BACKGAMMON 


(i)  See  [WULF  73]  for  a discussion  of  this  topic. 
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while  the  path  for  the  second  GENMEM  is 


ROLLDIE,  PLAYER.2<-J0HN,  GENSEQ,  START,  BACKGAMMON 


Treated  in  this  node  format  there  is  no  ambiguity  in  calculating  access  paths  because  every  event 
when  v H rCeSt°[!  ! J’°mS"  in  the  AcC6SS  Graph  0ccur  0n|y  Wl,hin  nodes-  which  are  rr, asked 

when  viewed  from  outside  the  node.  ° 


BACKGAMMON 


START 


REST-OF-GAME 




INSERT 

* 

PLAYER.  1 = JOE 

T 


FIRST-MOVE 

Figure  30.  An  Access  Graph  in  node  format 
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by  moving  tt'  7Th77"”!  I'1*  PEG  Th*  aCCSSS  Pa,h  a"  «“•  is  boterminod 

n nt  I ,8,  . hen  n0  leff  lmk  ex^ts),  with  all  events  included  except  those  which  are 

path  lor  Insert?®  a"d  reaChed  by  3 le"  lin‘''  Fi5Ure  5 (repea,ed  ,or  the  access 


COMPARE,  GEMSEQ,  START,  BACKGAMMON 


C 


BACKGAMMON 


START  REST-QF-GAmT) 


r genseq  ^ 

1 

' 

PLAYER.  1— JOE 

t- 

PLAYER.  2-*-  JOHN 

/ 

, 

ROllDIE 


INSERT 


-)  C *OUdQ  ^PLAYER.  1 = JOe)  (jERMINAL^) 


C GEN^MEM  ) ( GENMEM^) 


G 


JOE  MOVES" 


CdIEVALiJT)  ^DIEVALJ-^"P) 


Figure  5.  A Process  Elaboration  Graph  (PEG) 
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START,  though  protected,  is  included  because  it  was  reached  by  an  up  link,  not  a left  one 
the  second  GENMEM  visits 


Similarly, 


ROLLDIE,  PLAYER.2<-J0HN,  PLAYER.  1<-J0E, 
GENSEQ,  START,  BACKGAMMON 


but  PLAYER.  1<-J0E  is  removed,  since  it  is  protected  and  was  reached  by  a left  link,  leaving 
ROLLDIE,  PLAYER. 2<-J0HN,  GENSEQ,  START,  BACKGAMMON 


as  its  access  path  as  before.  The  box,ng  operation  done  to  the  Access  Graph  is  reflected  in  the  PEG 

by  never  moving  down  in  tracing  access  paths  since  the  down  link  represents  the  execution  of  the 
compound  event. 


Fn  S ' 0r!ue  IlLl"  event’s  access  Path*  a node  maY  be  inspected  under  the  proper  conditions 
or  example,  the  INDtX  iunction  was  designed  for  just  that  purpose.  However,  the  question  raised  in 

crol'er'  ‘3  COncernmp>  a P|-AYER--2  request  to  the  graph  in  Figure  29  forces  the  definition  of  those 
proper  conditions. 


acres*  m T ,n  GCrr,e  serse-  W3S  to  aUow  any  descendant  of  a compound  event 
access  to  its  information.  It  only  remained  to  decide  how  to  "linearize"  a compound  event  for 

Fo r Ufhe “T*  ^ '°3'Cal  Ch°iC6  'S  t0  COnSider  the  node  in  reverse  time  sequence, 

hor  the  GENSEQ  node  in  Figure  30,  that  sequence  is 


DIEVAL.  1 <- i , GENMEM,  ROLLDIE,  PLAYER.2<-J0HN 
DIEVAL. l<-3,  GENMEM,  ROLLDIE,  PLAYER.  1<-J0E 


The  algorithm  for  this  process  is 
LINEARIZE  (NODE) 

1.  If  NODE  is  NIL  then  return. 

2.  LINEARIZE  each  son  of  NODE,  rightmost  son  first. 

3.  Print  NODE 

When  a node  has  no  sons,  then  the  recursive  call  in  line  2 will  be  LINEARIZE  (ML);  hence  the  test  in 
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In  an  ALGGLized 


version  of  LISP,  the  algorithm  is 


(LINEARIZE 
[LAMBDA  (NODE) 

(if  NODE-NIL 
then  NIL 

else  if  N0DE:RIGHT-UNK  EXISTS 
then  (APPEND  (LINEARIZE  NODZiRlGHF-UNK) 

(APPEND  (LINEARIZE  NODL-DOWN-LINK) 

(LIST  NODE))) 

else  (APPEND  (LINEARIZE  NODE:DOWiM-LINK  (LIST  NODE]) 


tS  2?"'  "r«T  """  • Ns.  o,  events  by 

linst  the  NODE'S  r,Ght-i.nk.  then  the  NODE'S  J i*  an^r  “ iT?^'65  'hiS  llS'  in  reverse  °'“er, 

-nse.  lakes  cane  embedded  nodes,  w^a^  IS  * 


w,th  LINEARIZE  defined,  a complete  access  path  algorithm  can  be  given. 

(ACCESS-PATH 
[LAMBDA  (NODE) 

(if  NODE=ROOT 
then  NIL 

else  if  NODE:LEFT-LINK  EXISTS 
then  (APPEND  (EVALUATE  NODc:LEFT-LII\IK) 
i (ACCES5"PATH  NODE:LEFT-LINi<)) 

else  'CONS  NODE:UP-LlNK  (ACCESS-PATH  N0DE:UP-LINK']) 

The  simple  function  EVALUATE  is  defined  to  be 


(EVALUATE 
[LAMBDA  (NODE) 

(if  NODE  is  PROTECTED 
then  NIL 

else  (LINEARIZE  NODE]) 

It  merely  eliminates  protected  nodes  reached  by  a left-link. 
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Notice  that  the  last  "else"  of  ACCESS-PATH  clause  handled  the  up-link  case.  In  this  situation, 
the  event  is  aoded  (accomplished  by  LISP's  CONS)  to  the  list  only,  not  operated  on  by  LINEARIZE 
Applying  ACCESS-PATH  to  INSERT  gives 

COMPARE,  LINEARIZE  (GENSEQ),  START,  BACKGAMMON 
as  desired,  while  applying  it  to  the  second  GENMEM  produces  the  same  result  as  before. 


4.7  THE  EEC  /IS I)  OTHER  EXECUTION  MODELS 


The  semantics  of  a program  executing  within  XREP  are  captured  by  the  PEG  in  depicting  all 
he  control  and  access  issues.  From  this  standpoint  XREP’s  execution  is  similar  to  that  found  in  any 

language  which  operates  out  of  a stack,  like  LISP  or  A!  GCL.  But  the  role  intended  for  the  PEG  is 
more  diversified. 


In  describing  his  Contour  Modei  as  a structure  which  defines  execution  of  block  structured 
programs,  Johnston  mentions  that  one  of  its  features  is  that  algorithms  and  records  of  execution  are 
separate  but  related  components  [JOHNSTON  71],  His  picture  of  execution  as  a contour  was 
specifically  designed  to  give  precise  meaning  to  all  phases  of  execution  of  block  structured 
programs,  including  passing  control  and  accessibility  of  data.  The  model  is  separate  from  the 
program  and  can  be  interrogated  independently, 


hne  PEG  has  the  same  flavor.  It  is  maependent  of  the  PLX  program  but  yet  is  carefully 
esigned  to  cap(ure  the  structure  of  the  production  rules  of  which  it  is  comprised.  Like  the  Contour 
Model,  a visual  display  of  execution,  available  for  analysis,  can  be  related  back  to  the  original 
program.  The  intent,  however,  is  not  semantic  definition,  but  understanding  and  debugging.  This  role 
accounts  for  the  inefficiency  in  never  deallocating  any  completed  processes,  a major  concern  of 
other  execution  models.  The  entire  history  of  the  execution  is  needed  for  debugging  purposes. 


In  XRE  access  paths  are  implemented  in  a configurable  way.  In  other  words,  each  node  in  the 
PEG  is  semiautonomouc,  a result  of  the  segmented  na*ure  of  production  rules.  If  access  is  needed  to 
a di  ferent  node,  tnen  a link,  oy  way  of  the  event  separators,  must  be  built  between  the  two  throuph 
the  access  path  mechanism.  The  "independence"  of  nodes  gives  the  debugger  specific  entities  on 
which  to  address  the  access  path  proolem.  By  building  or  inspecting  the  links  between  nodes  the 
program  can  be  properly  structured.  In  SIMULA  [DAHL  66],  an  ALGOL-based  simulation  language,  a 
similar  situation  exists  in  linking  processes  together.  A process  in  SIMULA  is  meant  to  be  a complete 
action  acting  on  its  local  data  and  on  data  generated  and  stored  within  other  processes  The  linkape 
between  processes  is  set  up  by  items  called  "elements"  declared  with.n  the  requesting  process  The 
thought  behind  this  organization  concerns  the  needs  of  simulation  systems.  The  demancs  of 
simulation  makes  >t  difficult  to  program  problems  in  standard  languages.  The  individual, 
nonhierarchicai  nature  of  a SIMULA  process,  together  with  explicit  programmable  links,  evidently 
better  reflects  simulation  s.tuations. 
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The  event  separators  in  PLX  are  very  similar  to  the  "elements"  of  SIMULA;  both  have  the  same 
basis.  In  SIMULA  processes  are  oest  described  as  separate  entities,  while  in  PLX  the  production 
rules  ere  also  meant  to  be  independent  in  nature.  Both  systems  needed  a way  to  get  the  separate 
process  to  communicate;  SIMULA  uses  a specific  pointer,  while  XREP  does  it  by  configuring  access 


All  the  features  and  capabilities  claimed  for  PLX  and  the  PEG  are  directed  toward  providing  an 
internal  model  which  captures  algorithms  acquired  by  an  Automatic  Programming  system  from  a 
natural  language  source,  and  which  is  amenable  to  debugging  analysis.  The  access  path  issues  of 
this  chapter,  though  emphasizing  the  former  concerns,  prepared  the  groundwork  for  many  of  the 
debugging  algorithms  of  the  next  chapter. 


s. 


INTENTIONS  AND  DEIIUGGINC 


S.l  INTRODUCTION 


Thus  far,  XREP  has  been  described  as  a system  composed  of  various  programming  constructs 
which  combine  to  provide  an  environment  suitable  to  Automatic  Programming.  The  overall  goal  is  of 
course  to  generate  (or  write)  correct  programs.  In  this  direction  this  dissertation  starts  from  an 
existing  program,  uses  expectations  in  the  form  of  intention  strings,  then  automatically  debugs 
certain  errors  that  arise  during  execution.  Before  the  details  of  XREP’s  intention  and  debugging 
mechanisms  are  described,  other  works  that  address  the  problem  of  writing  correct  and  reliab!e 
programs  will  be  reviewed:  Section  5.2  describes  "standard"  programming  systems,  Section  5.3 
describes  aspects  of  the  program  proving  process,  while  Section  5.4  covers  automatic  debugging 
systems.  Each  section  will  emphasize  the  expectations  of  a system,  how  they  are  received,  and  how 
the  system  uses  them  to  help  find  and  correct  errors. 


5.2  SYSTEMS  FOR  WRITING  PROGRAMS 


Systems  which  provide  environments  for  programmers  deal  with  a class  of  errors  normally 
associated  with  programming  details  — bad  syntax,  misspellings,  etc.  They  fall  into  two  basic  groups: 
static  compile-time  errors  and  dynamic  run-time  ones.  In  trying  to  cope  with  either  set,  the  software 
system  can  only  assume  or  expect  that  the  programmer’s  input  is  rational,  and  that  any  simple, 
detectable,  obvious  error  should  be  repaired  if  possible. 


In  a batch  environment  the  only  expectation  held  by  a compiler  is  that  the  input  is  intended  to 
make  sense.  So  when  PL/I  repairs  a program  by  inserting  missing  semicolons,  progress  has  been 
made,  beyond  the  infuriating  FORTRAN  error  message  that 

GO  TO  (10,20,30,40)  I 

is  missing  a comma  after  the  right  parenthesis.  In  any  case,  purely  syntactic  errors  are  not  that 
interesting  in  this  environment,  while  run-time  ones  only  cause  immediate  failure. 


INTERLISP  [TEITELMAN  74]  will  be  the  model  for  the  discussion  of  what  can  be  done  by  an 
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INTFRMCP  n~T  sys‘ern'  n flddltl0n  t0  Pr0vidinS  a series  of  interactive  debugging  tools(i), 
,n  'JVh  I u0V\erSTriTrSP"0riented  edlt0r  and  an  automatic  error  correction  package  named  DWIM 
, rlha V Mnan  fTEITELK/AN  731  0WiM  d0es  automatic  spelling  correction,  syntax  modification,  and 
LISP  b3Sed  00  rUn'  'me  ana!y5iE  °f  Pr03ram  errors.  DWIM  works  well  because  it  knows  about 


In  his  PhD.  dissertation,  Vonke  develops  a system  which  has  similar  capabilities,  but  which  is 

vSrV^' dePdndent-  2ince  is  dr'(i) (ii) * * ven  by  external  language  specifications  (written  by  an  expert) 
L U E 75].  Both  systems  show  what  can  be  accomplished  if  the  computer  is  allowed  to  be  more 
active  in  the  program  construction  process,  even  though  working  in  a task-independent  domain. 


’>■3  PROGRAM  PROVING  SYSTEMS 


The 

programs. 

describing 

verification 


intent  of  the  program-proving  community  is  to  provide  formal  methods  for  verifying 
In  their  framework  a program  is  augmented  with  strategically  placed  assertions  tor 
what  should  be  happening  at  various  points  in  the  process.  From  these  assertions, 
conditions  can  automatically  be  generated  and  then  proved  in  various  ways(ii). 


The  assertion  language  in  current  research  is  typically  some  dialect  of  the  first-order 
predicate  calculus.  Its  role  is  to  provide  a second  description  of  the  program,  where  the  program 
itself  IS  the  first  — the  assertions  are  thus  redundant  specifications  of  the  program.  On  the 
assump.ion  that  its  assertions  are  an  accurate  statement  of  the  programmer’s  intention,  the  program 
is  forma. ly  proved  by  verifying  that  every  execution  will  satisfy  all  the  assertive  conditions.  The 
assertions  are  thus  the  system’s  expectations  for  the  program(iii). 


One  problem  with  this  technique  is  that  the  first-order  predicate  calculus  is  not  very 
expressive  and  can  produce  detail  in  almost  incomprehensible  quantities.  Trying  to  prove  the 
verification  conditions  becomes  a large  task,  difficult  for  either  man  or  machine.  An  interactive 

p r o o f s ^GOOfD ^5 b]  US6d  m 006  pr°Sram  verific5tl0n  57stem  so  that  the  user  can  help  guide  the 


What  seems  to  be  needed  is  higher  levels  of  abstraction  in 
whatever  level  of  description  satisfies  the  user.  If  a program  is  to  be 


the  assertion  language, 
proved,  a description  of 


or 

its 


(i)  See  [MANN  73]  for  a survey  of  these  debugging  tools. 


(ii)  See  [EISPAS  72]  for  a con.piete  review  of  this  process. 

(in)  In  fat  , Buchanan  and  Luckham  automatically  generate  some  simple  programs  from  assertions 

an  appropriate  set  of  axioms  [BUCHANAN  74],  The  formal  method  of  generation,  based 

theorem-proving  techniques,  guarantees  that  the  resulting  program  is  correct. 


and 

on 
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intent  is  mandatory.  However,  if  it  is  going  to  be  as  difficult  to  write  assertions  as  it  is  to  write 
programs,  then  the  cost  and  feasibility  of  this  process  are  open  to  question. 


D.  Good  recognizes  this  problem  and  suggests  a programming  environment  in  which  programs 
and  assertions  are  stepwise  refined  together  from  the  start  of  the  development  phase  [GOOD  75a], 
Thus  a program  can  be  proved  at  various  levels  of  abstraction.  For  this  idea  to  work,  expressive, 
formal  assertion  languages  are  needed. 


If  we  are  to  construct  proved  programs  of  significant  size  and  complexity,  then  it 
seems  that  we  should  . . . state  precise  specifications.  Obviously,  we  must  be  able 
to  state  the  specifications  before  we  can  prove  that  the  program  meets  them. 
Although  some  progress  has  been  made  in  this  area.  . .stating  specifications  for  a 
program  remains  a difficult  problem.(iv) 


Many  of  the  phases  of  program  proving  are  being  automated  in  one  form  or  another.  One  that 
has  just  begun  is  automatic  debugging.  Many  difficult  problems  need  to  be  solved  before  automatic 
debugging  is  realistic.  The  next  section  will  shew  the  complexity  of  some  systems  which  do  attempt 
it  in  some  restricted  domain. 


5.4  AUTOMATIC  DEBUGGING  PROGRAMS 


The  three  programs  reviewed  in  this  section  come  from  MIT,  each  with  the  flavor  of  Artificial 
Intelligence.  Each  attempts  to  solve  complex  tasks  within  a well  specified  domain  by  applying  its 
expertise"  to  problem  situations.  The  automatic  correction  accomplished  by  each  reflects  a deep 
understanding  of  the  associated  problems. 


In  his  dissertation  about  understanding  LOGO(v)  programs,  Goldstein  uses  an  external  model 
language  to  describe  the  intent  of  a picture  [GOLDSTEIN  74].  The  picture  drawn  by  the 
accompanying  LOGO  program  is  then  matched  against  the  model.  If  a difference  is  detected  between 
the  diagram  and  the  model,  debugging  occurs. 


Figure  31  shows  how  to  describe  a simple  line  drawing  of  a tree  in  the  model  language. 
Figure  32  shows  a LOGO  program  whose  intent  is  to  draw  that  tree  together  with  its  result.  Several 
model  violations  are  readily  apparent,  specifically  M4,  M5,  and  M7.  Using  those  violations  as  its 
debugging  impetus,  h ■=  system  produces  the  converted  program  in  Figure  33. 


(iv)  D.  Good,  "Provable  Programming."  International  Conference  on  Reliable  Software,  Los 
Angeles,  April  1975,  pg.  411, 

(v)  LOGO  is  a graphics  system,  devised  by  Seymour  Papert,  intended  for  children. 
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MODEL  TREE 

Ml  PARTS  TOP  TRUNK 

M2  LINE  TRUNK 

M3  EQUITRI  TOP 

M4  VERTICAL  TRUNK 

M5  COMPLETELY-BELOW  TRUNK  TOP 

M6  CONNECTED  TOP  TRUNK 

M7  HORIZONTAL  (BOTTOM  (SIDE  UP)) 

END 


Figure  31.  A Goidstein  tree  model 


TO  TREE! 

10  TRIANGLE 
20  RIGHT  50 
30  FORWARD  50 
40  RIGHT  50 
50  FORWARD  100 
END 


; version  1 
<-  (accomplish,  top) 
<-  (setup  heading; 

<-  (setup  position) 

<-  (setup  heading) 

<-  (accomolish  trunk) 


TREE  1 
VERSION  1 


Figure  32.  Incorrect  tree  program 


TO  TREE1 
5 RIGHT  30 

10  TRIANGLE 
20  RIGHT  60 
30  FORWARD  50 
40  RIGHT  90 
50  FORWARD  100 
END 


i version  4 

<-  (setup  heading  such-that  (horizontal  (side  3 top))) 
<-  (assume  (enter  TREE  1 statement  5)  (=  iheading  0)) 
<-  (accomplish  top) 

<-  (setup  heading) 

<-  (retrace  (side  3 top)) 

<-  (setup  heading  such-that  (vertical  trunk)) 

<-  (accomplish  trunk) 


F.gure  33.  Corrected  tree  program 


Notice  that  the  model  language  is  different  from  the  assertion  concept  of  the  last  section  in 
that  it  describes  the  output  of  the  program,  rot  intermediate  states.  The  adequacy  of  the  model 
language  is,  however,  hard  to  ascertain,  since  the  class  of  programs  handled  by  the  system  does  not 
allow  conditionals,  variables,  recursion,  or  iteration.  The  complexity  of  the  debugging  effort  is 
somewhat  foreboding,  considering  these  restrictions. 


In  his  work  on  model  debugging,  Bill  Mark  has  a less  formal  intention  language  [MARK  74].  In 
his  system  the  user  specifies  a "goal"  along  with  the  model.  If  the  goal  is  not  attained  during 
simulation  of  the  model,  it  is  debugged  with  that  goal  as  its  driving  target.  For  example,  a particular 
business  model  may  be  set  up  which  is  expected  to  make  six  sales.  If  only  five  are  made,  the  user 
give  5 the  system 
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(GOAL  (INCREASE  SALE  1)) 
as  it  goes  into  a debugging  mode  to  find  the  cause  of  the  failure. 


Gerald  Sussman’s  dissertation  has  the  character  of  both  Goldstein’s  and  Mark’s  programs. 
Goldsteins  effort  is  classical  in  intent:  a flawed  program  is  debugged.  In  Mark’s  work  a model  of 

unintended  interactions  prevent  the  goal  from  being  attained.  Sussman’s 
ACKER  lSUSSMAN  73]  is  given  a goal,  but  in  the  problem  solving  framework  of  the  blocks  world.  In 
solving  the  problem  HACKER  tries  to  find  an  applicable  program;  if  none  is  available  it  writes  One.  In 
either  case,  execution  of  the  program  may  manifest  a bug  which  HACKER  will  try  to  resolve  if 
possible.  HACKER’s  intent  is  not  to  ju:k  solve  any  specific  problem,  but  to  write  generalizable 
programs  for  handling  a class  of  reiated  problems. 


For  example,  in  Figure  34  the  scene  with  two  blocks  and  a table  is  the  setting  for  the  request. 

(MAKE  (ON  A B)) 


HACKER  finds  a simple  program  to  do  it. 


TABLE 


Figure  34.  Scene  for  (MAKE  (ON  A B)) 


e same  request  is  made  for  the  scene  in  Figure  35,  a bug  occurs,  since  the  simple  program 
cannot  move  A since  C is  on  it.  The  program  manipulator  receives  the  error  message  and  patches 
the  performance  program  so  that  C is  first  put  on  the  table  and  then  A is  put  on  B 


- TABLE 


Figure  35.  A more  complex  scene  for  (MAKE  (ON  A B)) 
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The  modification  to  the  resulting  program  is  general  enough  to  solve  the  same  problem  for  the 
scene  in  Figure  36. 


TABLE 


Figure  36.  A generalized  scene 


HACKER  basically  handles  three  types  of  errors:  unsatisfied  prerequisites  (eg.,  the  case 
above),  protection  violations  (eg.,  a subgoal  is  undone),  and  violation  of  domain-specific  "aesthetic" 
principles  (eg.,  moving  the  same  block  twice)  by  storing  information  about  them  in  many  different 
system  modules.  The  attack  on  a bug  is  a complex  dialogue  between  various  independent  system 
components,  each  with  expertise  in  a specific  area.  The  closed,  noninteractive  nature  of  HACKER  is 
impressive  in  performance  but  perhaps  causes  unnecessary  complexities  in  the  general  program 
debugging  task. 


Each  of  these  theses  enters  the  new  automatic  debugging  area  in  a familiar  way,  with  specific 
problems  in  specific  domains.  However,  each  derives  techniques  which  can  be  extracted  from  the 
work  and  incorporated  in  an  interactive  Automatic  Programming  type  of  system  as  a set  of 
possibilities  for  trial  and  discussion.  The  immediate  impact  of  these  works  will  come  not  from  results 
within  closed  systems  where  myriads  of  second-order  problems  obscure  their  possible  contributions, 
but  from  their  availability  as  high-level  debugging  tools  within  smart  software  environments. 


S.S  X REP'S  INTENTION  STRING  MECHANISM 


As  described  in  Seciion  2.5,  program  expectations  are  communicated  to  XREP  via  a string  of 
discrete  events  which  are  to  be  matched  against  the  results  of  the  TERMINAL  events.  When  a match 
fails,  a potential  bug  may  have  been  uncovered.  The  system  tries  to  identify  it,  relate  its  findings  to 
the  user,  then  suggest  a particular  debugging  technique.  Used  this  way,  the  intention  string 
provides  an  interface  between  XREP  and  the  user  in  a form  usable  by  both.  The  power  of  this 
method  comes  from  the  freedom  and  flexibility  of  both  the  content  of  the  TERMINAL  statement  : nd 
its  placement  within  the  program.  If  either  is  restricted,  then  generality  is  lost  in  potential  stages  of 
program  development. 
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In  the  program -proving  work  correct  placement  of  the  assertion  statements  is  fundamental;  all 
the  analysis  depends  on  proper  sequenong  through  those  statements.  But  only  the  first-order 
predicate  calculus  assertions  are  allowed  thus  far,  forcing  the  user  into  detail  in  which  he  may  not 
be  interested.  The  quotation  from  Good  on  page  70  indicates  that  the  range  of  possible  program 
descriptions  must  be  expanded  if  they  are  to  contribute  to  all  stages  of  a program’s  development. 
XREP  has  that  capability  but  without  the  security  of  formal  proof  procedures. 


The  assertion  language  in  Goldstein’s  LOGO  work  is  restric’ed  in  both  dimensions.  Besides 
requiring  full  descriptions  of  the  compieteo  picture,  his  system  makes  it  completely  external  to  the 
target  program.  This  separation  may  be  clean,  out  it  seems  to  add  unnecessary  complexity  to  his 
analysis,  since  he  must  derive  all  the  sequencing  information  himself.  The  modularity  in  picture 
composing  makes  the  program  segments  functionally  related  to  part  of  the  Overall  diagram,  so  that 
the  corresponding  assertions  have  a well-defined  place  in  the  program  while  general  statements 
could  be  located  at  the  beginning  of  the  program,  much  like  the  program-proving  work.  The  "<-" 
comments  on  each  line  of  his  LOGO  code  perform  exactly  these  functions,  adding  yet  a third  source 
of  redundant  information,  one  which  relates  the  declarative  model  to  the  actual  program.  Actually 
the  amount  of  redundancy  Golostem  reqi  res  should  be  an  omen  for  Automatic  Programming  work; 
his  method,  with  three  deser  ptive  information  sources,  may  be  exactly  the  right  one  for  proper 
program  generation  and  debugging. 


Comparing  XREP’s  intention  string  mechanism  to  Sussman’s  HACKER  is  difficult.  The  main 
source  of  er  'Ors  handled  by  Sussman  are  those  wnich  can  be  classified  as  implicit  program 
specif  cation  errors.  In  other  words  a program  which  HACKER  uses  or  writes  is  expected  to  conform 
to  specifications  located  in  various  system  modules.  While  the  system  pursues  its  goal  statement, 
those  modules  may  complain  that  they  are  being  vioiateo.  The  deougger  tests  the  validity  of  their 
claim,  taking  the  appropriate  act. on.  The  direction  for  all  actions  comes  from  the  goal  statements. 


Sussman’s  goal  statements,  like  (MAKE  (ON  A B)),  are  very  much  like  the  declarative  models  in 
Goldstein  s work.  They  are  simple  in  form  but  more  difficult  to  attain  because  Sussman  tries  to 
generalize  learned  techniques,  handles  recursive  and  iterative  situations,  and  writes  the  programs 
automatically.  His  simple  primitives  allow  more  com.plex  processing,  while  Goldstein,  in  the  richer 
LOGO  language,  must  restrict  himself  to  a LOGO  subset  to  achieve  comparable  results.  Still,  Sussman 
works  hard  at  doing  all  the  processing  automatically,  generating  all  his  own  subgoals  and  so  forth. 
He  n«  no  way  of  specifying  intermediate  results,  which  may  aid  in  the  problem  solving. 


The  philosophy  of  XREP,  which  is  not  in  the  problem-solving  business  until  debugging  time,  is 
that  any  information  useful  to  producing  a program,  should  somehow  be  able  to  be  incorporated  into 
the  program  description,  whether  it  be  intermediate  results,  general  information  about  the  state  of 
the  process,  or  just  redundant  material.  The  intention  mechanism  will  have  many  of  those 
capabilities. 


Remember  that  the  intention  string  not  only  aids  the  debugging  process,  but  also  glides  the 
top-down  execution  of  PLX  programs.  The  ncndetermimstic  choice  point.,  in  PLX,  either  rule  choices 
or  GENMFMs,  are  forced  down  the  the  right  path  in  trying  to  match  the  intention  string.  If  a 
GENMEM  generates  a die  value  like  4 and  the  intention  string  expects  5,  the  execution  will  back  up 
to  that  GENMEM  until  a 4 is  generated.  S.milarly,  a bad  rule  choice  will  be  undone  in  order  to  try  to 
match  the  current  state  of  the  string.  Th'S  is  the  nature  of  the  parsing  operation. 
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T„he  sedl0n?  01  lhi!  will  discuss  various  program  errors  ard  the  debugging 

delec  ion  oTh?'  !?  ^ ^ CaS°S'  ,hC  »i,l  be  fundamental  ,n  the 

0f  bugs-  whl,e  als0  Proviang  the  necessary  information  to  the  debugger  to  properly 
modify  the  program  to  alleviate  the  problem.  properly 


5.6  GENERAL  ERROR  DISCUSSION 


automatic  debugging 


is  determining  exactly  where  an  error  has 


The  most  difficult  task  in 

difficrur|f(wi!nhirthifeStf0n  ? \bUg  USUa',y  is  0bvi0uS:  ass'Sn>ng  responsibility  is  much  more 
difficult  (witness  the  extraordinarily  complex  control  structures  of  the  debugging  programs)  If 

backtracking,  automatic  or  otherwise,  is  part  of  the  program's  control  strudure.X  problem 
ecomes  even  more  complicated.  The  consequence  of  these  observations  is  that  success  in  a closed 
system  comes  from  careful  domain  restrictions. 


Since  XREP  is  "domain-independent,"  it  addresses  a different  class  of  problems  than  those 
HACKER^  associated  w„h  problem  solving.  Sussman  tned  to  make  this  same  d, Stine, ion  wdhm 
HACKER  by  keeping  general  programming  knowledge"  separate  from  specific  "block  world"  details 

Ixec^ion' r , th  handJeS  are  aSS0Ciated  with  pr°Sram  writi"S  which  are  detectable  at 

ecution  time,  not  those  whicn  might  require  problem  solving  in  the  translation  phase  in  order  to 
just  get  a program  statement(vi). 


The  Phllos°Phy  wi,hin  XREp  <s  to  assume  that  the  system  can  "help"  detect  errors  and  make 

‘nterpctivITv*  f°r  cor,<!c,<"S  lh8m-  0f  “urse,  accept.ng  advice  from  a human  in  an 

“ ' ! , abou'  lh"  preMrce  °f  source  of  a bug  should  be  welcome,  even  if  the 

the  aooToach  «PP  rrT‘,U'P5f  !°  ,iX  i('  The  SllUati0"5  WhiCh  ,°"°w  in  succeeding  sect.ons  take 
back, ,ack°or  accept  ’ P 5 “"d  °"erS  * SO'Ulion  Which  the  user  can  re)ecl  'sousing 


S.7  UNIIOUND  Vmhm.KS 


The  first  problem  to  be  analyzed  is  the  case  of  the  unbound 
common:  a variable  does  not  point  to  bound  value.  Consider  the  PLX 


variable.  The  situation  is  quite 
program  in  Figure  37. 


Wf)  See.  [BALZER  74b]  for  a description  of  a Model  Completion  task  within 
Programming  system  which  addresses  that  translation  problem. 


an  Automatic 
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A B , C 

B (GENMEM  DIEVAL* 

C :=  D.E.F 
D :=■  (TERMINAL  ’IN  D') 

E (TERMINAL  ’IN  E LOOKING  FOR'  DIEVAL  - 
F (TERMINAL  ’IN  F’) 

Figure  37.  Unbound  variable  example 


If  this  program  is 
that  In  Figure  38 


rur',  its  PEG  just  oefore  executing  the  TERMINAL  statement  of  E will  look  like 


A 


GENMEM 


DIEVAL.  1—6 


\ 


C 


TERMINAL 
"IN  D" 


ngure  33.  Partial  PEG  for  program  in  Figure  37 


context  Mth~oH^an  6 'h"'  a E accfsse5  DlE'/AL'1-  However,  since  no  such  binding  exists  in  the 

The  problem  stems  from  the  production  rule 

A :=  B , C 

rh7rea„Uep?rat^T.OCC^:fodbat7''e  C « erroneously  protected  from  event  B bec.use  0. 
separator  , . To  produce  the  proper  Access  Graph  the  rule  snould  read: 

A :=  B ->  C 
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GENMEM 


DIEVAL.  1^—6 


X * X 

D E F 


TERMINAL 
"IN  D" 

Figure  39.  Repaired  Access  Graph 


This  example  simplifies  what  has  actually  happened  because  the  flaw  shows  up  so  vividly  in  the 
production  system.  In  generating  a program  in  a top-down  manner  a designer  defines  different 
levels  of  abstraction  from  which  his  program  can  be  viewed.  Each  level  is  complete  as  a "machine" 
assuming  the  right  primitives(vii).  If  a structural  flaw  like  this  one  occurs,  it  is  probably  a case  of  a 
machine  needing  access  to  one  which  is  at  the  same  level.  In  this  example,  the  hierarch>  of 
computation  makes  the  process  B a black  box  to  that  of  C.  Yet  it  seems  that  it  should  be  otherwise 
if  the  PLAYLR.-l  request  is  valid.  The  reorganization  described  resolves  exactly  that. 


(vii)  This  is,  of  course,  Dijkstra’s  simile  in  his  Notes  on  Structured  Programming  [DAHL  72]. 
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The  procedure  to  repair  this  problem  will  be  called  tne  NO-BIND  algorithm.  Its  descriot.on 
given  in  terms  of  the  PEG,  not  the  Access  Graph.  Figure  40  shows  the  original  PEG  for  this  example 
annotated  by  the  local  symbols  of  the  algorithm.  P ’ 


Fig'. re  40.  Annotated  PEG  for  program  in  Figure  37 
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The  algorithm,  invoked  when  an  access  from  event  CURRENT  to  TYPE  fails, is  as  follows: 


NOBIND  (TYPE,  CURRENT) 


1.  Find  a previous  event,  EP,  which  has  an  instance  of  TYPE  in  it. 

2.  Find  the  common  rule  ancestor,  CA,  to  both  CURRENT  and  EP. 

3.  Inspect  the  production  rule  for  CA  for  the  form 

CA  X ....  Y ..  . 

where  X is  in  the  context  path  of  EP  and  Y is  in  the  context  path  of  CURRENT. 

4.  Change  that  production  rule  for  CA  into 

CA  :«  . . . X ->  . . . Y . . . 

5.  Back  up  the  process  to  the  event  following  X and  continue  execution  from 
there. 


In  tne  example  EP,  the  previous  target  event  is  the  GENMEM.  The  common  rule  ancestor,  CA, 
is  event  A.  X is  event  B ; Y is  event  C . The  rule  change  in  Step  4 makes  the  B event  in  Figure  40 
oval  instead  of  rectangular,  thus  making  the  GENMEM  accessible  to  event  C and  all  its  descendants. 


A few  other  things  should  be  stated  about  the  algorithm.  In  Step  1 the  context  path  of  EP  is 
not  subsumed  by  the  context  path  of  CURRENT;  otherwise  TYPE.-i  would  be  accessible  to  it. 


In  Step  2 the  common  rule  ancestor  may  be  different  frorn  the  common  ancestor  if  viewing  an 
Access  Graph.  The  PEG,  however,  makes  this  distinction  obvious.  Note  also  that  there  may  be  more 
than  one  rule  whose  change  might  solve  the  problem.  The  algorithm  picks  the  "nearest"  (in  terms  of 
time  sequence)  first. 


In  Step  3 a rule  like 


CA  X , Z . . . Y 

may  be  the  culprit.  However,  changing  it  to 

CA  :=  X ->  Z . . . Y 
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STSrTlT. !I?s'Sh,"  “ w,°"‘  01  r‘  NoaND 

.ppli,  *on°  l °'  ,h#  04  '*  '»  «“«"•»  • »»  l.rsl 

from  i|,  first  ,nu",Zn  “ M°"‘  '*  'C  ”*  ”»  r.st.rt 


rSSr“-™i^E 

algorithm  to  produce  F^ure  43.  8 ^ f:,n  b®  repa,red  bV  tw0  applications  of  the 


L 


type.i  TYPE.  1 


L :«  V , N , C 
M 'GENVEV!  TYPE) 

N (GENMEM  TYPE) 

0 (TEUW.fjAL  TYPE.-2) 

E ?ure  42.  A TYPE. -2  access  failure 
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Figure  43.  The  repaired  version  of  Figure  42 


5.8  W liONG  II  IN  DINGS 


The  solution  to  the  unbound  variable  error  of  the  last  section  involved  reorganizing  access 
paths  to  make  the  proper  information  available  A byproduct  of  I hat  reconfiguration  is  that  all  the 
information  in  the  path  of  the  once  missing  type  becomes  available  to  the  original  requestor.  For 
example,  in  Figure  39,  event  E now  has  the  DIEVAL  binding  in  its  path  as  required,  but  everything 
else  generated  by  event  3 is  available  not  only  to  E,  but  to  D and  F as  well.  This  situation,  which 
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may  or  may  not  be  desirable,  will  be  investigated  further  in  Chapter  6,  where  an  alternative 
method  for  solving  those  particular  unbound  var.abie  errors  will  be  suggested.  With  that  in  mind, 
the  usefulness  of  the  NOBlND  algorithm  might  be  open  to  question.  However,  the  examples  in  this 
section  present  situations  in  which  the  algorithm  performs  substantive  modifications. 


The  case  of  a wrong  binding  is  more  complicated  than  the  unbound  variable  situation  because 
of  the  larger  variety  of  possible  solutions  and  possible  errors.  In  the  unbound  case  not  much  can  be 
done  until  some  binding  is  found.  The  manifestation  of  the  wrong  binding  error,  however,  is  likely  to 
occur  during  a match  of  a TERMINAL  to  tne  ntention  string,  when  much  more  information  is  available. 


Consider  the  Access  Graph  fragment  in  Figure  44.  If  the  rule  for  event  F is 

F (TERMINAL  ’MOVE’  TYPE.-2) 
and  the  current  state  of  the  intention  string  is 

. . . (MOVE  4)  . . . 

then  a failure  occurs  since  the  terminal  ou’out  m F would  be  (MOVE  5).  Assuming  that  TYPE.l  is 
supposed  to  be  5 and  not  4 (perhaps  verified  by  an  earlier  match  in  the  intention  string),  then 
(unless  a major  flaw  is  responsible)  the  problem  could  be  a simple  error  in  the  reference 
specification  with  the  TERMINAL  event,  TYPE.-2  should  bt  TYPE.- 1. 


The  only  debugging  t"ac  can  be  done  here  is  to  check  the  other  bindings  n that  access  path 
and  see  if  one  works,  'f  so,  then  some  sort  of  confirmation  is  required  and  the  change  „•  the 
production  rules  is  a simple  one.  If  the  access  was  done  via  some  arbitrary  expression  like 
TYPE.(ADD  X Y),  then  little  help  can  be  rendered. 


Note  that  this  s mple  technique  can  be  tried  if  an  access  like  PLAYER.-2  hzs  no  binding.  If 
PLAYER.-l  does,  it  might  be  the  correct  one.  Thus  this  method  should  be  trier/  just  before  the 
NO-BIND  algorithm  is  attempted. 
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TYPE. 1 — 5 


GENMEM  GENMEM 


f 

2—4 

I 


Figure  44.  An  access  graph  fragment 


TYPE.  2—  3 


TYPE. 


A more  subtle  rase  occurs  when  there  is  a structuring  error.  Suppose  the  rule  for  F in  Figure 

44  is 


F (TERMINAL  ’MOVE’  TYPE.-l  ’AND’  TYPE.-2) 
and  the  current  state  of  the  intention  string  is 

. . . (MOVE  4 AND  3)  . . . 

Then  the  failure,  due  to  the  mismatch  of  the  TERMINAL  output  (MOVE  4 AND  5)  and  the  intention 
string  (MOVE  4 AND  3),  is  not  so  easily  repaired.  The  search  for  the  proper  binding  s jcceeds 
outside  '.he  current  access  path,  indicating  the  need  for  an  application  of  the  NOBIND  algorithm.  The 
resulting  Access  Graph,  shown  in  Figure  45,  resolves  the  problem. 
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TYPE.  1*^-5 


t 

I 


GENMEM 


TYPE.  2-*- 3 


GENMEM 


TYPE.  3—4 


Figure  45.  A linearized  modification  of  Figure  44 


The  most  substantive  error  situation  is  the  inverse  of  the  last  example.  With  Figure  45  as  the 
starting  point  and  the  same  F rule  as  the  preceding  paragraph,  the  intention  string 

. . . (MOVE  4 AND  5) . . . 

would  provoke  an  error  since  (MOVE  4 AND  3)  results  from  the  TERMINAL  event.  The  fix  in  this  case 
to  turn  Figure  45  into  Figure  44  ~ comes  from  changing 

E (GENMEM  TYPE)  ->  (GENMEM  TYPE  (->  F)) 


to 


E (GENMEM  TYPE) , (GENMEM  TYPE  (->  F)) 

In  other  words,  the  event  separator  " ->  " must  be  changed  to  a This  modification  is  just  the 
opposite  of  what  the  NOBIND  algorithm  does,  hence  the  inverse  notion.  A simple  modification  to  that 
algorithm  allows  it  to  handle  this  error  condition. 
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Notice  that  without  the  intention  string  to  guide  the  results,  very  little  could  be  done  in  these 
situations.  The  information  conveyed  by  the  matching  process  of  TERMINALS  to  the  intention  string 
gives  XREP’s  debugger  a firm  basis  on  which  to  diagnose  the  problem.  Even  if  the  situation  is  one 
which  cannot  be  handled  by  XREP,  the  attempts  it  makes  will  at  least  be  reasonable. 


r,.i>  RECURSION  /INI)  STRUCTURE  FAULTS 


The  las!  section  described  errors  relating  to  binding  issues  which  were  quite  clear-cut  and 
needed  debugging.  Now  a different  kind  of  problem,  will  be  viewed,  one  in  which  there  is  "nothing" 
technically  wrong.  Instead  the  error  will  be  strictly  related  to  poor  structure  and  an  intuition  about 
how  a particular  Access  Graph  should  lock. 


This  problem  has  a natural  evolution  and  substantial  basis  arising  out  of  a typical  situation.  An 
existing  program  needs  to  be  modified.  If  tne  changes  are  made  with  only  a local  or  narrow  view  of 
the  problem,  the  resulting  program  can  develop  a "patched-together"  look.  In  fact,  HACKER  gets 
exactly  this  kind  of  criticism  from  Sussman  himself.  His  system  creates  a program  in  an  evolutionary 
manner  without  the  ability  to  step  t-,ck  and  review  it  as  a complete  entity.  This  is  obviously  not  a 
charge  against  HACKER,  for  that  ability  spans  the  entire  intellectual  programming  discipline.  Still, 
some  "global"  improvements  can  be  made  in  a program  if  some  assumptions  are  allowed. 

The  Backgammon  example  will  again  be  the  model.  The  actual  rules  for  the  start  of  a game 
need  to  be  extended  from  those  given  on  page  11.  The  complete  statement  is  as  follows: 


Tito  game  starts  by  haring  ouch  player  roll  a dir.  Tltc  player  with  the  largest 
value  makes  the  first  move,  consisting  of  his  roll  anrl  the  roll  of  the  other  player. 
In  ease  of  a tie  the.  value  of  the  cube  is  doubled,  and  the  process  is  repeated. 


The  cube,  initially  1,  represents  the  value  of  the  game  in  any  arbitrary  unit.  Ignoring  the  tie 
condition  for  the  moment,  the  program  is  shown  in  Figure  46. 
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BACKGAMMON  :»  START  , REST-OF-GAME 

START  (GENSEQ  PLATER  T (->  ROLLDlE))  ->  COMPARE 

ROLLDIE  :=  (GENMEM  DlEVAL  T)  -> 

(TERMINAL  PLAYER.-I  ’ROLLED’  DIEVAL-1) 
COMPARE  :=  (INSERT  PLAYER.dNDEX  MAX  DlEVAL))  ->  FIRST-MOVE 
FIRST-MOVE  (TERMINAL  PLAYER.-l  'MOVES’ 

DIEVAl.1  FROM  PLAYER.-l  'AND'  DlEVAL  1 FROM 
PLAYER.(FIND  (i\IEQ  PLACER  PLAYER.-l))) 

REST-OF-GAME 

Figure  46  Backgammon  program  without  tie  condition 


This  program  is  essentially  the  sarnie  as  the  previous  ones  except  for  the  added  detail  h ;he 
TERMINAL  events.  The  ROLLDIE  nonterminal  now  -ndudss  an  observation  of  the  rolling  process,  and 

the  I .o  i -MOVE  TERMINAL  makes  th*>  move  exp'icit  in  terms  of  die  values  (as  given  in  the  English 
statement  above). 


Given  the  following  initial  API  top-level  assertions 

(ASSERT  (AMO  JOE  PLAYER)) 

<ASSERT  (AMO  JOHN  PLAYER)) 

(ASSERT  (AMO  1 DlEVAL)) 

(ASSERT  (AMO  2 DlEVAL)) 

(ASSERT  (AMO  3 DlEVAL)) 

(ASSERT  (AMO  A DlEVAL)) 

(ASSERT  (AMO  5 DlEVAL)) 

(ASSERT  (AMO  6 DlEVAL)) 

(ASSERT  (VALUE  CUBE  1)) 

the  execution  of  this  program  will  match  an  intention  string  like 

(JOE  ROLLED  5)  (JOHN  ROLLED  3)  (JOE  MOVES  5 AND  3)  . . . 

My  initial  attempt  to  implement  the  tie  condition  quite  naturally  involved  only  the  addition  of  another 
compare  rule  to  handle  the  failure  of  the  INDEX  function’s  attempt  to  return  a unique  PLAYER  when 
their  die  values  are  the  same.  The  program,  including  this  new  rule,  is  shown  in  Figure  47. 
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BACKGAMMON  START  , REST-CF-GAME 

START  (GENSEQ  PLAYER  T (->  ROLLDiE))  ->  COMPARE 

ROLLDIE  (GENMEM  DIEVAl  T)  -> 

(TERMINAL  PLAYER. -1  ’ROLLED’  DIEVAL.-l) 

COMPARE  (INSERT  PLAYER.( INDEX  MAX  DIEVAL ))  ->  FIRST-MOVE 
COMPARE  :»  (TERMINAL  PLAYER.- 1 ’AND’  PLAYER.-2  ’TIE’  ) -> 

(FUNCTION  (ASSERT  VALUE  CUBF.  (ITIMES  2 (VALUE  CUBE))))  -> 

(TERMINAL  'CUBE  TURNED  TO’  (VALUE  CUBE))  ->  START 
FIRST-MOVE  (TERMINAL  PLAYER.- 1 ’MOVES’ 

DIEVAL. i FROM  PLAYER.- 1 ’AND'  DIEVAL.  1 FROM 
PLAYER.(FIND  (NEQ  PLAYER  PLAYER.- 1))) 

REST-OF-GAME  . 

Figure  47.  Initial  attempt  to  implement  the  tie  condition 

The  new  COMPARE  rule  has  four  parts.  The  first  TERMINAL  is  an  announcement  that  the  two 
players  tied.  The  FUNCTION  statement  assorts  to  the  API  data  base  that  the  value  of  the  cube  is  to 
be  twice  the  old  vahje,  with  the  next  TERMINAL  expression  announcing  that  fact.  Finally  the  process 

(VAmFr^Bn  ° *°4  r<fPeat-  °ne  simP|lficatio"  ha*  been  introduced.  The  expression 

(VALUE  CUBE)  is  an  abbreviation  for 

(F$*  NUMBER  (VALUE  CUBE  NUMBER)) 

This  FS*  function,  first  explained  in  Section  3.2,  returns  as  its  value  the  number  which  matches  the 
da  a base  assertion  (VALUE  CUBE  NUMBER).  Thus  the  FUNCTION  statement  asserts  that  the  new 
value  of  the  cube  is  twice  the  old  value. 


This  new  program  was  tested  on  two  intention  strings.  With  the  Original  cube  value  at  1 (an 
initial  assertion)  the  strings  were 

(JOE  ROLLED  5)  (JOHN  ROLLED  3)  uOE  MOVES  5 AND  3) . . . 


(JOE  ROLLED  4)  (JOHN  ROlLED  4)  (JOHN  AND  JOE  TIE) 

(CUBE  TURNED  TO  2)  (JOE  ROLLED  5) 

(JOHN  ROLLED  6)  (JOHN  MOVES  6 AND  5) . . . 

...  ,.The  ,irst  f,nn*  is  th®  0n3'nal  the  second  reflects  the  tie  condition.  In  trying  them  out 
with  the > "®w  rules  it  was  rewarding  to  see  everything  work  perfectly,  at  least  until  I looked  at  the 
Access  Graph  for  the  second  intention  string.  Figure  48  shows  in  abbreviated  form  what  actually 
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I did  not  expect  generation  numbers  for  PLAYER  to  be  3 or  4.  They  became  that  high  because 

Granh?^  |GEHStEhQ»htld  the  firSt  GENSEQ  in  its  access  P#th'  Working  backwards  from  the  Access 
Graph,  I realized  that  the  proper  structure  should  be  like  the  one  shown  in  Figure  49. 


BACKGAMMON 

/ \ 

ST|*T  REST-OF-GAME 

GENSEQ 

/\ 

PLAYER.  !♦- JOE  PLAYER. 2^-JOHN 


"TIE" 

I 

(ASSERT  (VALUE  CUBE  2)) 

I 

START 

i 


GENSEQ 


PLAYER.  3 — JOE  PLAYER.4— JOHN 

I I 

• t 

Figure  48.  The  Access  Graph  for  the  tie  example 
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to  theTIpronHLHSl0n  ',r  F'8Ur!  48,°“urred  3t  to°  low  a leve|.  irrelevant  information  available 

to  the  second  d.e-rollmg  node.  In  Figure  49  that  situation  was  remedied  by  makm°  the  recursion 

onC which  to  Han  th*  GENSEQ'  Th,s  f,x  reduires  the  presence  of  a new  simple  event”  INITIAL-MOVE, 
Figure  50  mana8e  ^ reCUrS'°n-  A new  sef  cf  rults  whlch  embody  the  fixed  PEG  is  displayed  in 


BACKGAMMON 


/ 


✓ 

START 


INITIAL-MOVE 

/ 


REST-OF-GAME 


(ASSERT  (VALUE  CUBE  2)) 


GENSEQ 


\ 


PLAYER.  1-*- JOE  PLAYER. 2 ♦•JOHN 


INITIAL-MOVE 


START 


DIEVAL.1—  4 


DIEVAL.l— 4 


COMPARE 


GENSEQ 


/ \ 


PLAYER.  1—-  JOE  PLAYER.:  *-JOHN 

! I 


"TIE" 


Figure  49.  Corrected  Access  Craph  for  the  tie  example 
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BACKGAMMON  :-  INITIAL-MOVE  , REST-OF-GAME 
INITIAL-MOVE  :-  START 
INITIAL-MOVE  :=  START  , 

(FUNCTION  (ASSERT  (VALUE  CUBE  OTiMES  2 (VALUE  CUBE)))))  -> 
(TERMINAL  ’CUBE  TURNED  TO’  (VALUE  CuBE»  ->  INITIAL-MOVE 
START  (GENSEQ  PLAYER  T (->  ROi.LDlE))  ->  COMPARE 
ROLLDIE  (GENMEM  DIEVAl  T)  -> 

(TERMINAL  PLAYER.-l  ’ROLLED’  OlEVAL.-l) 

COMPARE  (INSERT  PLAYER.dNDEX  MAX  C.EVAl))  ->  FIRST-MOVE 
COMPARE  (TERMINAL  PLAYER. -i  ’AND'  PLAYER. - 2 ’TIE’  ) 
FIRST-MOVE  (TERMINAL  PLAYER -1  ’MOVES’ 

DIEVAL. 1 FROM  PLAYER. -i  ’AND’  OlEVAL.l  FROM 
PLAYER.(F,ND  (NEQ  PLAYER  PLAYER.-l))) 
REST-OF-GAME  :-  . . . 


Figure  50.  Corrected  Bacr.gamm,on  rules 


_ ”^he  imPOrtant  differences  >n  this  new  set  of  product. ons  appear  in  the  rules  containing 
INMAL-MOVE.  The  first  :NITIAl-MOVE  rule  anticipates  *ne  non  t.e  condition,  while  the  second  is  for 
the  case  when  a tie  occurs(vm). 


The  point  of  these  rule  charges  is  to  force  the  "tie"  recursion  to  occur  at  INITIAL-MOVE 
instead  of  START,  so  that  each  GENSEQ  node  will  oe  unique  within  its  access  path,  solving  the 
problem  of  PLAYER  generation  numbers  becoming  higher  than  two. 


Two  issues  now  present  themselves:  How  is  this  problem  detected  and  how  can  it  be  fixed’  If 
a program  runs  “correctly”  (i.e.,  matches  its  intention  string),  then  some  explicit  method  must  be 
devised  to  give  the  system  the  impetus  to  deoug.  One  way  is  via  constraints  on  the  generation 
numbers.  That  is,  in  fact,  how  this  problem  originally  presented  itself. 


The  solution  is  to  allow  assertions  which  state  the  maximum  limit  for  specific  types.  If  that 
limit  is  exceeded,  then  the  RESTRUCTURE  algorithm  (to  be  presented  shortly)  will  be  offered  to  the 
user.  For  the  BACKGAMMON  program,  the  assertion 

(ASSERT  (MAXSIZE  PLAYER  2)) 


is  added  to  the  top  -level  set. 


(viii)  If  the  first  INITIAL-MOVE  rule  is  chosen  and  a tie  game  is  being  parsed,  the  failure  of  the  rule 
does  not  occur  in  START  (since  a tie  will  still  be  declared  by  the  second  COMPARE  rule)  but  in  the 
failure  of  REST-CF-GAME  to  have  the  right  beginning  information:  a unique  player,  two  different  die 
values,  etc. 
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Tine  Kind  o'  problem  is  difficult  to  formalize  because  of  its  wide  range  When  an  implicit 
assumption  --  whether  bu.lt  into  a program  or  unstated  by  the  user  --  is  violated,  some  system 
module  must  recognize  the  situation  and  act  accordingly  Sussman's  HACKER  has  a Critics  Gallery 
which  watches  over  the  coae  genera!or  so  that  when  a proposed  program  statement  is  about  to 
violate  some  condition,  the  appropriate  critic  will  complain.  This  demon(ix)  approach  seems  to  imply 
that  each  assumption  needs  its  own  critic  or  expert,  a possibility  which  may  cause  a computational 
explosion  Automatic  Programming  efforts  wiH  undoubted./  uncover  many  of  these  cases. 

The  RESTRUCTURE  algorithm,  invoiced  by  tne  detection  of  a generation  number  overflow, 
follows.  The  PEG  for  this  example,  snown  in  Figure  51,  is  annotated  by  the  locals  of  the  algorithm, 
while  some  of  its  obvious  Imics  are  not  included  Remember  that  this  PEG  represents  the  Access 
Graph  of  Figu-e  48. 


RESTRUCTURE  (GUILTY) 

1.  Find  the  rule  father,  RF,  of  the  GUILTY  GENMFM  or  GENSEQ. 

2.  See  if  RF  appears  twice  m the  current  contpxt  path.  If  not,  the  algorithm  fails. 

3.  If  so,  f nd  the  g-anefathers  of  each  R-;  call  them  GF1  and  GF2.  Let  the  two 

rules  GF 1 and  G"?  have  the  following  form: 

GF1  X sop  1 RF  sep2  v 

GF2  :«  Z sep  MOVASuE -STuFF  sep  PF 

4.  Mane  tne  following  changes  to  the  program.  Change  the  GF1  rule  to  be 

GF1  X sepl  TEMP  sep2  Y 
Change  the  GF2  rule  to  be 

GF2  :»  Z 

Insert  the  rules 
TEMP  :•-*  RF 

TEMP  RF  , MOVABLE-STUFF  ->  TEMP 


(ix)  A demon  is  a module  which  oversees  execution  and  is  invoked  when  some  specific  condition  is 
met.  P ./ 1 ON  Conditions  are  an  example  of 'iemon  p ngrams. 
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5 To  compute  which  events  ccmpr  se  MOVABLE-STUFF,  inspect  the  original  GF2 
rule  from  right  to  eft,  ignoring  RF.  For  every  Ei  encountered  do  the 
following: 


j)  If  Ei  ma ken  a reference  to  a previous  event  wmch  cannot  be  moved,  then 
Ei  cannot  be  moved.  Th  s decision  may  have  to  be  delayed  by  step  b 

b)  If  Ei  mar.es  any  assert  ons  a-d  nas  aexendants  which  cannot  be  moved, 
t cannot  be  moved.  Othe' w se  it  can;  this  includes  the  case  where 
depenoents  are  wa  t rg  for  a dec  s.on  about  Ei  itself. 

c)  T.ne  process  stops  wren  Ei  cannot  be  moved. 


1F1 


(t 


BACKGAMMON 


5 


■f  : 


-l — ii. 


START 


G 


<i 


'tut  It  If 


REST-OF-GAME 


GFl 


J 


GENSEQ 


"^COMPARE^— ^FIRST-MOVr) 


c 


1 


movablt~»  tuff 

X 


FFl 


TERMINAl'y^FUNCTIO^m^TERMIN/u)— >{TtART  ^ 


Currtnt 


"TIE" 


ASSERT  "CUBE  TURNED 
TO  2" 


^GENSEQ  J-~ 


Figure  51.  The  annotated  PEG  for  Figure  48 


A few  statements  should  be  made  about  this  algorithm  before  tracing  it  for  the  BACKGAMMON 
example.  Tha  MOVABlE-STUFF  computation  is  done  to  find  those  events  which  will  not  be  affected 
by  the  relocation  performed  by  the  RESTRUCTURE  algorithm.  The  move  is  both  aesthetic  (since 
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MM 


MOVABLE-STUf-F  no  lon<ic~  need  contend  with  the  irrelevant  information  it  was  under)  and  functional 
(since  its  information  might  be  needed  for  descendants  of  the  new  TEMP  nonterminal).  Notice  that  if 
a nonmovable  event  is  needed  under  the  second  instantiation  of  TEMP,  an  irresolvable  conflict  will 
arise;  XREP  s NOBIND  algorithm  trying  to  undo  the  work  of  RESTRUCTURE,  which  will  in  turn  be 
remvoked  by  the  same  generation  number  overflow.  This  problem,  unsolvable  in  the  given 
framework,  will  be  addressed  further  in  the  conclusion,  Chapter  6. 


The  algorithm  will  now  be  traced. 


In  (1)  START  is  the  rule  father  (RF)  of  tne  GENSEQ  which  tries  to  generate  PLAYER.3,  violating 
the  (MAXSlZE  PLAYER  2)  assumptions. 


In  (2)  START  does  appear  twice  m the  context  path  of  the  guilty  GENSEQ. 


In  (3)  GF1  is  the  BACKGAMMON  nonterminal,  while  GF2  is  the  second  COMPARE.  The 
productions  in  question  are 

BACKGAMMON  START  , REST-OF-GAME 

COMPARE  (TERMINAL  PLAYEP.-l  'AND*  PLAYER.-2  'TIE'  ) -> 

(FUNCTION  (ASSERT  VALUE  CUBE  CTIMES  Z (VALUE  CUBE))))  -> 

(TERMINAL  'CUBE  TURNED  TO'  (VALUE  CUBE))  ->  START 


In  (5),  to  determine  MOVABLE-STUFF,  inspect  the  three  events  of  the  COMPARE  rule  (ignoring 
START)  from  right  to  left.  The  (TERMINAL  ’CuBE'  . . ) event  instantiates  (VALUE  CUBE),  so  a 
decision  must  be  delayed  until  the  source  of  (VAlUE  C*j3E)  is  determined.  In  the  FUNCTION 
statement  an  assertion  is  maoe  which  uses  (VALUE  CUBE).  In  this  case  (VALUE  CUBE)  is  known  to 
originate  from  the  initial  top-level  assertions  (i.e.,  nothing  done  by  the  program).  Thus  it  can  be 
moved,  as  can  the  delayed  event  (TERMiNAl  'CUBE"  . . .),  which  depends  on  it  The  (TERMINAL 
PLAYER.  I . . .)  event  instantiates  two  items  — PLAYEP.-l  and  PLAYER.  2 — whicn  are  part  of  the 
original  GENSEQ;  it  therefore  cannot  be  moved,  ending  step  5. 


Now  step  4 can  be  completed.  The  four  affected  rules  are 

BACKGAMMON  TEMP  , REST-OF-GAME 
TEMP  START 
TEMP  :«  START  , 

(FUNCTION  (ASSERT  (VALUE  CUBE  (ITlMES  2 (VALUE -CUBE)))))  -> 
(TERMINAL  'CUBE  TURNED  TO’  (VALUE  CUBE;)  ->  TEMP 
COMPARE  (TERMINAL  PLAVER.-l  'AND*  PLAYER.-2  ’TIE’) 


These  rules  are  as  advertised,  TEMP  taking  the  role  of  INITIAL-MOVE  of  Figure  50. 


INTENTIONS  AND  DEBUGGING 

5.10  PRECONDITIONS  /INI)  POSTCONDITIONS  IN  RECURSION 


The  restructuring  techniques  derived  in  the  last  section  can  be  applied  to  a class  of  algorithms 
exemplified  by  the  instructions  which  might  be  found  on  a shampoo  bottle. 


1 ) Wet  hair 

2)  Lather 

3)  Rnse 
A)  Repeat 


Statement  4,  the  source  of  the  problem,  does  rot  specify  the  starting  iteration  point;  where  should 
we  repeat  rom.  Notice  also  that  no  matter  wnat  teraton  point  is  chosen,  the  lack  of  a terminating 
condt.on  will  cause  this  algorithm  to  loop  forever.  These  kinds  of  flaws  are  typical  of 
um,n-or  ented  instructions:  the  user  ,s  supposed  to  apply  common  sense  to  a situation  to  resolve 
ambiguities  n the  shampoo  example  everyone  would  repeat  from  Step  2 since  wetting  already  wet 
ha  r is  nonsensical.  Hardly  anyone  would  lather  up  more  than  twice. 


rm  , jIT  P|r0blem’  a,f10rg  0,herS*  15  described  I.  0.  Hill  in  h,s  paper  about  programming  in  English 
VLL  S ",essa-e  !S  clear;  Automatic  Programming  will  have  to  cope  with  poorly  specified 

aigoritnms  and  find  methods  to  cor-ectiy  translate  them. 


Given  no  other  information,  a like  y guess  for  the  starting  point  of  the  shampoo’s 

Ant  IC  t rn  Q Kfln  nn.nM  . * * L . •«  • , ... 


- - / ,,,w  1 " '5  Kwnf  wi  me  snampoo  5 repeat 

statement  ,s  the  beginning  one,  ’wet  ha.r."  Meeting  the  infinite  loop,  that  interpretation  ,s 
ncorrec  because  it  includes  a precond.t  on,  wetting  the  hair,  ,n  its  ma,n  loop  body.  A program  , 
HLX  for  this  simple  aigomthm  is  shown  in  Figure  52. 


SHAMPOO 

WET-HAIR 

LATHER 

RINSE 

REPEAT 


WET-HAIR  ->  LATHER  ->  RINSE  ->  REPEAT 
(TERMINAL  'WETTING  HAIR’) 

(TERMINAL  ’LATHERING  HAIR’) 

(TERMINAL  ’RINSING  HA.fi*) 

SHAMPOO 


Figure  52.  The  shampoo  program 


As  written,  the  program  will  generate  a terminal  string  like 

(WETTING  HAiP)  (LATHERING  HAIR)  (RINSING  HAIR) 

(WETTING  HAIR)  (LATHERING  HAIR)  (RINSING  HAIR) 

(WETTING  HAIR)  . . . 

However,  a correct  intention  string  for  the  shampoo  exercise  would  be 

(WETTING  HAIR)  (LATHERING  HAIR)  (RINSING  HAIR) 

(LATHERING  HAIR)  (RINSING  HAIR) . . . 


The  detection  of  the  precondition  error  in  this  simple  example  from  the  correct  intention 
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•jtr  ng  is  not  complicated.  If  a TEPM!NAL  generates  a nonmatching  string  which  has  occurred  before, 
the  precondition  error  might  he  hypothesized.  If  the  program  is  Jlowed  to  continue,  and  the  next 
TERM.NAL  does  match,  tnen  the  hypothesis  is  strengthened.  In  the  shampoo  program  the  second 
(WETTING  HAIR)  string  does  not  match  the  intended  (LATHERING  HAIR).  If  continued,  the  program  will 
however  generate  (LATHERING  HAIR)  as  desired.  The  precondition  problem  seems  to  be  at  fault(x). 


The  REMOVE-PRECONDITION  algorithm  to  be  presented  shortly  assumes  that  *he  precondition 
event,  PRE-EVENT  (the  second  (WETTING  HAIR)  string),  and  the  desired  event,  DESIRED-EVENT  (the 
second  (LATHERING  HAIR)  string),  have  been  identified.  The  algorithm  and  an  annotated  abbreviated 
PEG  follow. 


REMOVE -PRECONDITION  (PRE-EVENT  DESiRED-EVENT) 


Find  the  common  rue  father,  RULE-FATHER,  for  PRE-EVENT  and 
DESIRED-EVENT. 


2.  Check  if  RULE-FATHER's  first  son,  PRE-FATHER,  generated  PRE-EVENT.  If  not, 
algorithm  fails. 


3.  Check  if  RULE-FATHER  has  already  appeared  in  the  PEG.  If  not,  fail. 


A.  Take  the  rule  in  question 

RULE-FATHER  :■  PRE-FATHER  sep  rest-of-rule 

and  rewrite  it  as  the  pair 

RULE-FATHER  :«  PRE-FATHER  sep  TEMP 
TEMP  rest-of-rule 

5.  Replace  instances  of  RULE-FATHER  in  I.  a right  hand  side  of  all  production  by 
TEMP. 


(x)  Since  having  a postcondition  in  the  mam  loop  is  exactly  symmetric  to  the  precondition  case,  it  will 
not  be  discussed  other  than  in  this  footnote. 
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SHAMPOO 


WET-HAIR  V-(  LATHER 


REPEAT 


■■uh  -fa  t he 


Wethng  hair)  (Lathering  hair)  (Rinsing  hair)  ( SHAMPOO' 


-i  ;’c  >: : 


! rc  -father 


WET-HAIR  w LATHER 


(Wetting  hair)  UcfLering  hair) 

/ / 

r- ceircd-cvcnt 


Figure  53.  Annotated  PEG  for  shampoo  program 


SHAMPOO  production  °n  ,he  SHAMPOO  program  is  shown  in  Figure  54  Th-  first 


SHAMPOO 

TEMP 

WET-HAIR 

LATHER 

RINSE 

REPEAT 


WET-HAIR  ->  TEMP 
LATHER  ->  RINSE  ->  REPEAT 
(TERMINAL  ’WETTING  HAiR’) 
(TERMINAL  ’LATHERING  HAIR’) 
(TERMINAL  ’RINSING  HAIR’) 
TEMP 


Figure  54.  Fixed  shampoo  program 


works  only  when  PRE-^VENT^nd*  DESiR^D-EVEf^T  carTace  "T,  been  described  The  algorithm 
of  the  SHAMPnn  h,  * j » b EVEr'jT  ca"  accurately  be  determined.  In  the  simple  case 

named  PRE-FATHER  (WET-HAIR  in  SHAMPOO  e3Sy’  ^ COns'der  ,he  Several  situation.  The  evert 
• - - 


96 


INTENTIONS  AND  DEBUGGING 


DFSIREdNwnt""  ’he  undMircd  PPS-EVEMT  may  change  the  evaluation  env.ronment 
DESIRED-tVENl,  mak.n;  ,1  laimatchable  with  the  intent, on  string  ,1  execution  ,s  continued 


for 


of  ^ ilc1VC  b6Pn  l0Cated>  tlie  rest  foilow&  ThlS  situation  is  similar  to  some 

[GREEN  74]  Their  research  ^ Wa'dmjer  in  the,r  aut0ma,ic  program  generation  work 

pair*  ellipses  J Z 5 “ Serera?,nS  pr0^™  fr0m  -put  descriptions,  1/0 

pa  rs,  ellipses,  etc.  One  of  the  examples  is  the  following 


iNPUT  OUTPUT 

(A  B C D)  ->  ((A  B)  <A  C)  (A  D]  (B  C)  (B  0)  (C  Dj) 


first  stlhoeof,fh«ed  P?Srar  iS’  °f  CClir$ei  SbpD0’ed  t0  generate  all  2-tuples  from  the  input  list.  The 
, ,r  nP  , ir  s/s  em  r es  t0  lCentlf7  the  recursion  point  in  the  output  list.  Once  (A  B)  (B  C) 

etLVVnT  ' ^ ^ be  S—ted'  ,f  tbis  '"ducfio"  Procesi  <1!« tUe 


bv  better  Th  ,S  ,rue  '"H*  RE^CV£-PR^0NDITI0N  algorithm.  Until  this  situation  can  be  resolved 
J b!a  debu8B-g  mechanisms,  implementation  of  the  algorithm  ,s  impractical.  Some  of  the 
necessary  improvements  will  be  discussed  in  Chapter  6. 


5 ,1  MSOI.VIXC  PROMOMhV.  KEI  IHU.XCI.S 


The  last  error  situation 
language  translation  programs. 


to  be  discussed,  resolving  pronomial  references,  is  common 
Charmak  states  the  general  reference  problem  as  follows: 


in  natural 


V ,eb  a c°irJpu,er  J^cr.  r.as  a top  and  Mary  also  has  a top,"  to  show  a minimum 
of  understanding  the  machine  must  realize  that  I have  mentioned  two  different 
tops.  It  will  need  some  way  to  distinguish  the  two  objects  internally,  and  since  in 
b°  h case?  1 “sed  the  phrase  "a  top,"  the  English  description  will  not  suffice.  We 

u TrsD-T8  ,hat  ,he  objects  are  rePresented  by  two  distinct  symbols,  say,  TOPI, 
and  IOP2.  Unfortunately,  when  people  speak,  they  don't  refer  to  T0P2,  they  say! 

Mary  s top,  or  the  top  Mary  found  in  the  woods."  It  will  be  necessary  for  our 
machine  to  take  such  English  descriptions  and  decide  which  (if  any)  internal 
symbol  is  oemg  referred  to.  This,  simply,  is  the  reference  problem.(xi) 


(xi)  E.  Charmak,  Context  and  the  Reference  Problem.” 
Rustin  (New  York:  Algorithms  Press),  1973,  pg.  3H. 


Natural  Language  Processing,  Ed.  by  R. 
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This  issue  has  been  addressed  several  times 
access  paths.  However,  when  the  reference  is  some 
more  difficult,  since  less  information  is  present. 


>n  this  report  in  describing  both  PLX  and 
pronoun  form,  the  reference  problem  becomes 


slat, Jem"0,!'  7lr'!TSUiee  C,°8rams'  "Mlvins  8 pr0n0mi81  reler'""  18  *"  i™"ediat.  concern: , 

w™8'8*  'zz 
;;  :::  sssa- 


representational  way  together  with  debugging  possibilities  ProV,d'"g  h"P  8 


Progra0;™V^^slah,or'",:„niM  rS.sZ‘Vnea  .k'y,'  V"8"0"  18  88  <»  the  Automatic 

decision  by  subs., hi Z a ^ pealica.  on  Le -??•  in  iL  T™  (?>  '"S"8d  « d'!=>8  * 

•’X"  donng  execution  £,  us^inC^in  ^ ~ ® '° 


TYPE.™:  niXP^nd'^x  n^'  ;e,erenCP  pr0b8bly  8PP888  ««•  ways: 

When  mere  th.;  one  exist-  The  ' e ond^L  8mb'8UPUS  r',ere"‘e  llke  "<h*  Player.- 

value."  The  last  „ the  worst  case'commg  from  ^e'eletnce"'  '"'e  """  ^ 


The  problem  is  solved  as  follows: 


h *h®  f'rSt  fS;t,0n  ,s  unkn0wn-  i-e-  equals  ?T,  each  possible  type  can  be 
yp  esized  to  see  if  the  reference  makes  sense.  This  step  will  be 

. sTTr^V7^1  '?*  Wi"  re!0lve  ,hP  prpb!pm  i8  encountered 
on  possible  types  [s  se^peVe  'h Sbl'  ^ 8 ‘h°iCe  pPW  b88pd 


l8ThERUI'“L  *bich  “ses  !Ws  variable  is  encountered  and  the  intention  string 
matches  other  than  this  unknown  variable,  the  proper  value  lor  >T  can  be 

ndention  shin*  ^ 'indi"3  ’he  ,h'  CP"e8pp"di"*  odiec.  in  the 


If  no  resolving  TERMINAL  is  found  but  the  program  concludes  correctly,  the 
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Hypothesized  type  assigned  in  Step  1 is 
program. 


assumed  correct  ard  inserted  in  the 


mu$t  a,so  ,ind  ,he 

FIRST-MOVE  :=  (TERMINAL  ?T.?X  ’MOVES’ . . .) 

If  the  intention  string  for  the  program  was 

(JOE  ROLLED  6)  (JOHN  ROLLED  1)  (JOE  MOVES  6 AND  1) 

(9T ’X  MOVEs" 6 ANPU ' eypress'0' s w,l‘  match  routinely.  But  when  FIRST-MOVE  generates 
found  to  bo  PLAYER  ThI "MrcTuTlter*'”  '=  needErt-  iS  r"a"hed  lo  J0E'  wh0«  type  is 


Though  this 
be  made. 


example  and  process  are  not  particularly  profound,  several  interesting 


points  can 


UiS  ^ °f  t!'r  i,Urntion  Strin*  »"**«  reference  problems  simple  to  solve. 


PI;  Vs  typed  variable,  T.X,  gives  the  reference  problem  a natural 
either  the  / or  \ component. 


interpretation  in 


The  access  path  search  emphasizes  how  this 
simplifies  the  task. 


dynamic. 


run-time 


approach 
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6.  CONCLUSIONS  AND  FUTURE  DIRECTIONS 


Tms  report  has  investigated  _some  representational  issues  for  both  writing  and  analyzing 
programs  within  a hypothetical  Automatic  Programming  framework.  The  motivation  for  many  of  the 
forms  and  analyses  originated  in  an  attempt  to  deal  with  situations  likely  to  arise  when  a human 
describes  an  algorithm  I.-  a computer.  Within  this  paradigm  the  goal  that  the  programming  language 
should  mirror  natural  language  methods  whenever  possible  accounts  for  the  production  system 
approach  to  PLX,  its  oata  types,  and  structured  organization.  Similarly,  the  problems  addressed  by 
the  various  debugging  discussions  were  meant  to  model  common  situations  which,  though  natural  in 
human  communication,  are  imprecise  or  ambiguous  in  computer  terms.  The  rest  of  this  chapter, 
divided  by  these  language  and  debugging  goals,  will  review  this  report’s  accomplishements,  and 
suggest  future  directions,  while  identifying  problems  discovered  during  the  course  of  the  research. 


6.1  TIIE  PRODUCTION  LANGUAGE 


My  original  thought  about  a target  language  for  Automatic  Programming  leaned  toward  finding 
a process  representation  which  was  both  machine  oriented  and  had  a "programming"  flavor.  A 
production-type  language  fulfilled  both  criteria,  satisfying  my  initial  goal.  Next,  I had  to  augment  the 
standard  notion  of  a production  language  with  capabilities  I envisioned  necessary  for  the  Automatic 
Programming  task:  intention  strings,  data  generators,  execution  history,  etc.  With  each  added 
capability,  PLX  too*  on  a more  important  role  in  the  project  than  I envisioned,  important  enough  to 
warrant  an  appraisal  of  PLX  as  a language  development. 


It  has  been  said  that  a new  programming  language  must  contribute  an  order  of  magnitude  more 
conceptual  power  to  gain  acceptance  as  a new  vehicle  [WILE  73].  That  measure  is  hard  to  apply  to 
PLX,  since  i was  not  designed  to  be  used  by  human  programmers;  an  appropriate  alternative 
benchmark  has  'ot  yet  been  established. 


What  can  be  measured  is  the  effectiveness  of  PLX  to  deal  with  its  three  main  issues: 

1.  PLX  as  a language. 

2.  The  control  structure  of  PLX. 

3.  The  data  generation  and  access  mechanisms. 
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l.niiRua/ro  Aspects 


First  of  all,  programs  can  be  written  in  PLX.  This  observation  reacts  to  the  range  of 
processes  for  which  PLX  is  intended,  i.e.,  those  which  Automatic  Programming  might  attempt  to  write. 
Though  only  a few  programs  (acludily  segment1-)  were  presented,  others  not  included  in  the  paper 
were  written  to  insure  that  the  language  constructs  used  were  adequate,  and  those  needed  were 
easily  implementab'e  as  well  as  consistent  with  the  formalism.  The  BACKGAMMON  segment  was 
sufficiently  complex  to  test  the  adequacy  of  many  of  my  representation  goals:  heterarchical 
organization,  natural  data  referencing,  and  so  forth.  If  an  Automatic  Programming  system  is  built 
around  a language  hhe  PLX,  the  present  research  will  provide  son e,  hut  not  all,  the  inputs 
necessary  to  configure  the  bes*  target  language.  Other  language  goals  not  tested  by  this 
study,  like  the  coherency  of  large  PLX  programs,  efficiency,  and  optimization,  also  need  to  he 
studied  before  any  final  conclusions  can  be  made.  Designing  a computer  language  is  an  evolutionary 
process;  PLX,  as  described  here,  is  a first  pass. 


Control  Structure  in  Pl.X 


The  control  structure  of  PLX  is  difficult  to  evaluate.  The  clarity  in  passing  control  from  event 
to  event,  and  the  simplicity  of  picking  production  rules  and  appending  them  to  the  PEG,  added 
substantially  to  understanding  the  behavior  of  a PLX  program.  However,  the  backtrack  mechanism 
for  driving  the  productions  was  a mixed  blessing.  Though  it  allowed  a "successful"  execution  to  be 
found  without  worrying  about  false  paths,  it  came  at  the  expense  of  making  firm  commitments  in  the 
error  detection  phase  impossible.  While  this  is  not  the  first  time  general  backtrack  has  caused 
probiems(i),  several  distinctive  situations  did  arise. 


if  a top-down,  syntax-driven  parser  picks  a production  which  causes  a failure,  the  process  is 
backed  up  to  the  bad  choice  and  a new  rule  is  chosen.  However,  consider  the  PLX  possibility  with 
the  two  rules 

A :*  (COND  pred)  ->  8 
A C 

An  ALGOL  interpretation  of  this  production  pair  might  be 


IF  pred  THEN  B ELSE  C 

If  the  predicate  in  the  COND  event  fails,  the  action  is  clear,  choose  the  A :=  C rule.  But  what  if  the 
predicate  test  passes,  8 is  entered,  and  a failure  occurs;  should  we  backtrack,  as  PLX  usually  does 
now,  or  debug9  In  the  ALGOL  case,  once  B is  entered,  C is  never  again  considered  in  this  iteration; 
in  PLX  the  failure  in  B is  ambiguous.  This  is  a general  issue  with  generative  systems:  how  is 
backtracking  prevented  when  real  errors  are  present9  The  utility  of  the  TERMINAL  statements  can 
be  seen  in  this  situation:  Event  B can  output  enough  information  to  identify  the  manifestation  of  a 
possible  error.  This  solution  will  not  take  care  of  all  cases,  but  it  is  certainly  adequate  for  a 


(i)  See  From  P I.AhNKR  to  CONNIV  I'.R  --  A Genetic  Approach  [SUSSMAN  72]  for  a similar  situation. 
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r 


substantial  set.  In  no  case  did  I ever  confuse  a real  error  with  a normal  backtracking  situation  (while 
watching  the  process  at  a terminal);  whether  a novice  will  be  so  adept  is  a different  question. 


A different,  less  substantial  issue  in  this  area  concerns  varied  control  structures  for  producing 
iteration.  Between  the  GENSEQ  and  production  rule  recursive  control  mechanism,  all  iterations  are 
possible.  However,  large  ones  could  easily  cause  an  explosion  in  PEG  size.  One  solution  might 
incorporate  some  loop  skeleton  Or  frame  structure  to  represent  a loop,  with  local  changing  values 
updated  as  indicated.  More  important  is  that  such  a frame  may  be  the  basis  for  understanding  loop 
execution  and  their  associated  problems.  In  any  case,  some  more  specific  loop  structures  are 
needed  in  a complete  Automate  Programming  target  language. 


Data  Generation  and  Access  Mechanisms 

■ 

The  data  methods  in  PLX  attempt  to  incorporate  a problem-solving  function  as  a syn*3ctic 
language  device  The  access  pat  1 searches,  the  relative  reference  types,  and  the  generators  all  try 
to  retain  and  use  dynamic  information  in  a manner  natural  to  English.  Keeping  these  functions  in  the 
language  shows  a f iox  bUity  of  expression  and  an  information  gain  which  would  be  lost  if  all 
references  were  resolved  (or  attempted  to  be  resolved)  at  translation  time.  The  major  contribution 
of  PLANNER  [HEWiTT  72]  was  the  fC'maiization  of  powerful  problem-solving  tools,  like  backtrack  and 
pattern  ir.vOKed  procedures,  into  a coherent  language.  PLX  does  the  same  with  its  typed  variables. 


The  basic  idea  in  accessing  dynamically  produced  data  is  that  data  has  a position  within  an 
execution  that  carries  information  which  can  be  exploited  to  the  system’s  benefit.  For  example,  the 
reference 

DIEVAL1  FROM  PLAYER.-2  FROM  ROLLDIE 

from  page  55  not  only  shows  how  an  ambiguity  can  arise,  but  gives  a graphic  interpretation  of  it  as 
we  I.  if  the  manifestation  of  all  problems  were  so  explicitly  capturable,  debugging  efforts  would  be 
minimized. 


A different  situation,  in  which  the  spatial  nature  of  data  is  nafural  and  easy  to  accept,  exists 
when  complex  linkage  between  two  data  items  is  necessary  before  an  association  between  them  can 
be  made.  For  example,  in  a card  game,  a request  for  all  the  Kings  a particular  player  holds  might  be 
something  liKe  (HAS  JOHN  KING).  Requests  like  this  generally  fail  because  players  have  cards  and 
ca'ds  not  players  have  rank.  So,  some  inference  mechanism  must  find  the  appropriate  linkage  to 
make  the  request  legitimate.  In  PLX  if  the  cards  are  generated  after  a player,  the  player  and  the 
cards  are  associated  merely  by  being  adjacent  in  the  same  access  path.  This  association,  powerful, 
simple,  and  intuitive,  is  easy  to  express  in  PLX. 


The  spatial  positioning  of  data  can  aiso  be  applied  in  a manner  not  currently  allowed  in  XREP. 
Recall  that  when  a typed  variable  is  unbound,  the  NOBIND  algorithm  tries  to  f nd  the  required 
instance,  then  reconfigures  the  access  paths  so  the  request  succeeds.  In  solving  the  problem,  the 
algorithm  makes  available  not  only  the  required  data,  but  everything  else  which  may  be  in  its  access 
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path  as  well.  This  linearization  process 
undesirable  if  an  alternative  exists. 


may  or  may  not  cause  future  errors,  but 


generally  it  seems 


to  another  5UHSeSM°n  ‘(alleCi  f°r  3n  !'NSfRT'l,ke  P"mi,ive  wh|ch  could  move  data  from  one  access  path 
hem  L hlo?  I “fu ,0"  much  hke  S'ving  an  access  path  a value  (or  values)  and  back!™ 

its  simplicity  6Since  t"  ' % ^ °herS  '°  tHen''-  Th'S  'dea  IG  m,rlSuinS  because  of 

si,’  r * pS"  , ' bp  d0ne  WI,P  COme  ^*t.c  primitive  much  like  INSERT,  the  debusing 

Enphsh  has  a rn  y 9^nMlwL  c°r'ce'"  15  Wlfh  *>w  natural  such  a construct  is;  I do  not  7, ink 
tnglish  has  a correspond  ng  construct. 


A different  solution  is  »c  permit  declarations  in  ‘he  language.  If  a reference  across  access 

acceMble6  FCted’tihe  °f  the  required  variable  .s  moved  high  enough  to  make  it  properly 

PU  t n.rl.  de;  ,,0nS  "*  "0l  Parl  01  nat,,fal  lan3uaee'  lncludlnS  them  a lanEua6e  like 

/ perfectly  sound;  certamiy  they  simplify  problems  like  these,  though  perhaps  only  locally. 


Enplish  £ FROM  < ' Ua,1°nG  PLX  '"aC  Sh°Wn  ,0  ha"e  3 ,0rm  "fltural|y  corresponding  to 

,1  Ct  . re,erence*  ar’d  the  iNDEX  and  ™ functions  handled  a variety  of  common 
situations.  Still  some  improvements  are  possible.  One  is  to  allow  a GENSEQ  or  GENMEM  to  produce 

;::rly  that  its  members  now  come  from  assertions  in  the  global 

, T ‘ "'a  'Ve  3 3 baSe  'Eee  page  lllls  facility  would  give  an  interpretation  to  a statement 

like  generate  a sequence  of  all  the  existing  players  who  have  a King  in  their  hands  " 


Fimn  r needed  is  a p.  ec  se  forma. ization  of  the  capabilities  of  these  methods.  The  INDEX  and 

f oub  A ’*  t m,,°  ’"I5  Ca,eSCry'  Wha'  are  ,hey  Capablp  0f  Sieving?  Wna,  situation  wSf  cause 

mtuat  on*-  railed^  £ * '?"*'**  °*n  a preC,Se  explana,l0n  be  formulated  for  the  anomalous 

I 2 y generation  number  problem  m Figure  27  or  tne  accessing  problem  in  Figure 

TH  a ques,l0ns  are  f'ard  to  address  in  the  present  configuration  of  PLX  because  the  exact 

ange  and  d of  the  functions  are  unKnown  The  lack  • formality  is  not  dis;u/bb*  e;aec;. 

exoe-  enCe  T k P*r,'Cular  ™*{i,0d  IS  generally  required  before  formalization  ,s  possible.  Some 

understanding35  83  ,he  exp5riments  of  thl*  dissertation;  more  is  needed  for  proper 


b.2  TIIF,  PEC,  INTENTIONS,  /)ND  DEHL'CCINC 


PFP  a 60  1 emS<°  hlS  sectl0n  are  Sr°uped  together  because  of  their  interdependence: 

2^’  a maJ°r  mfprma,l0n  s*ructure  relating  execution  to  the  production  rules,  guides 

debugging  nrocess,  wh.ch  ;s  in  turn  often  activated  by  intention  string  failures.  Each  wil 
reviewed  as  an  entity  and  as  a part  of  XREP. 


The 

the 

be 
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The  PEC 


The  need  for  all  execution  information  within  a debugging  system  is  mandatory.  The  PEG  not 
only  has  that  information,  but  has  it  stuctured  to  correspond  to  the  original  program.  The 
explicitness  of  this  correspondence  was  a design,  goal  from  the  start  of  the  project  --  one  that 
proved  its  worth  throughout  all  the  debugging  exercises.  It  was  rewarding  to  find  that  the  PEG 
could  maintain  that  relationship  while  yielding  to  a fairly  straightforward  implementation. 


The  Intention  String 


The  intention  string  mechanism,  on  the  other  hand,  is  iess  well  understood.  It  represents  an 
informal  attempt  to  orovide  XREP  with  parsing  capabilities;  the  intention  strings  comprise  the 
language'  of  acceptable  output  for  a program  in  much  the  same  manner  that  formal  languages  can 
be  described  by  a BNF  "program."  In  the  latter  case  the  Output  strings  are  programs  themselves;  in 
the  former  the  strings  are  merely  some  observation  of  a program's  behavior. 


The  parsing  ability  is  < natural  way  of  matching  three  redundant  specifications:  the  program, 
the  TERMINAL  events,  and  the  intention  string.  It  is  interesting  that  the  redundancy  of  English 
dialogueiiii)  constantly  gives  the  listener  reassuring  feedback  to  aid  understanding.  Old  programming 
languages  never  considered  ncorporatmg  such  mformation(iii). 


One  of  the  complaints  about  the  first-order  predicate  calculus  as  an  assertion  language  s the 
stilling  amount  of  detail  with  which  the  user  must  contend.  A similar  argument  might  apply  to  the 
intention  string  mechanism.  Whether  or  not  it  is  too  bulky  for  practical  use  remains  to  be  seen,  but 
its  flexibility  will  allow  any  level  of  detail  by  way  of  the  TERMINAL  events.  In  fact,  different  parts  of 
a program  can  mix  the  desired  detail  in  order  to  focus  on  specific  modules  or  to  deempha;ize 
modules  which  have  been  shown  to  be  reliable.  Without  that  capability  any  specification  mechanism 
is  suspect.  Research  in  this  area  is  just  beginning  and  is  sure  to  have  an  impact  on  fu'ure 
programming  practices. 


Debugging 


This  dissertation  has  placed  XREP  into  a general  program-writing  environment  (whether  an 
Automatic  Programming  type  or  an  INTERUSP  type  is  not  important  for  the  moment).  Thus  its 


(ii)  See  [HALPERN  66]  for  a discussion  of  the  role  of  redundancy  in  English  and  its  possibilities  n 
computer  languages  founded  on  English  principles. 

(iii)  A new  ALGOL  dialect,  ALGOL  W [SITES  72],  has  incorporated  an  ASSERT  statement,  while  tht 
program  proving  system  described  in  [GOOD  75b]  has  augmented  PASCAL  [JENSEN  73]  with 
assertion  statements,  but  only  for  their  own  use. 
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sszt.es  ,ound  ,n  mo,e  -t—*  *•*--  *. 

describes  this  phenomenon T ler^s  oiT^uTol  *77  ^ ^ Sack™" 

interact  in  trymo  to  venerate  „rnorim  . ..  PUjh'pul1  rnodel-  a Programmer  and  computing  system 

programmer  pushes  in  the  same  direction  VaCKMAN  W ^TheT^d"™61,  ''°  3 S°lu,l°n’  wh,!e  the 

systems  is  to  give  the  system  more  freedom  in ^ts  work  e it  pulk  the'n  n"  m°der"  pr°8rarnr"inS 
f nal  solution  before  ri,in,  control  bir*  to  ' ’ P L"  h Programmer  nearer  to  the 

.wended  to  work  in  d, recbon  programme,.  XREP's  debu8B,„8  algor, Ihms  „e 

representations  o7fe'IdXeXREpdve|;?hriroh0n'"r,’,h  beC'MJSe  H'ey  depend  s0  sPecif, tally  on  lire 
rirerelore,  ralne,  man  dwelf upon' me!, X We“  "will0; U"p?  77*  — 

work  and  how  they  can  be  improved.  ” XREP>  Wl  discuss  wh^t  makes  them 


understanding  syste^  c°aTon°y  wo^rm'100  ,0S*,her  W th  fl  COmPiete  execution  history,  an 

before  substantial  analysis  m noTibie  T„  H°wever’  muth  "»'«  's  necessary 

ol  power  of  match, n8  TERMINAL  output  s'™”,  trmTm'renUn'T*  *^P  was  in  "le  lacl' 

one-for-one  process  which  ir  not  door,  u“f  ,e  l0n  s,rmS-  Basically,  the  match  is  a 

situations  leading  to  the  REMOVE-PRECONDl^ON  algtdhVoTsecbo0!  ^ 


-ut,reAs  could^cceM^ foT^el^v^nce^^^^  17^7^°"  7* 

necessary.  When  a match  lads.  Ihe  loiiowmg  should  be  JjJrt  " n°'  S'mP'e-  bu' 


• How  similar  is  the  output  to  the  target? 

• Will  some  simple  reoraermg  within  the  string  work9 

• Has  the  output  appeared  before? 

• Coes  th*  current  output  occur  later  m the  expected  output? 

• Has  some  pattern  developed  which  allows  a system  prediction’ 


r:  r:za  t*-  * h-  -* 

0WhlydsPli:nadd,'K  d'",CU"  Pr0S""’  ™ d'dbl-=.  w^ere 


.nvirolT "5h«\!?oiX“  l^rTH,U'T,i'K,rr0r  Cb"K'“  * ™ 

more  difficult.  Continued  research  into  clasi  L n "*7?.  U blJS  ,s  an  order  of  magn‘lude  (at  least) 
design  ol  a “library"  of  debupsinp  technim  a w ^ daonz,n5  ab°ut  bugs  can  actually  follow  Ihe 
once  he  has  himself  idenlihed  . bug  ’ ”S  aC"Va'ed  by  “ ^ user  as  a ,0dl 
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